Re: Default exclude rules for Git

[Junio C Hamano <gitster@pobox.com>]

Petr Baudis <pasky@suse.cz> writes:

> I think it would actually make most sense to insert some conservative
> default ignore rules to the Git's stock excludes template. (Or better,
> have a single file with default Git's exclude rules. Tools newly
> installed on the system could even add their entries there during
> installation as Git's quest on world dominations progresses.) I'd
> shamelessly propose Cogito's set of default excludes for starters:
>
> 	*.[ao]
> 	.*
> 	!.git*
> 	tags
> 	*~
> 	#*
>
> (or omit the first line if that feels too C-specific - but I think it
> should be extremely rare to find files you _want_ to track even in non-C
> projects; and I'd argue anytime that by default ignoring hidden files
> is absolutely the sanest thing to do.)

I do not see a need to change any canned template shipped with git.  I
actually think it is a grave regression to add anything arbitrary, even if
one person happens to think the choice is conservative, to the set of
tool-wide ignore patterns.  And here is why.

I haven't personally seen any project that wants its users to _edit_ a
file whose names end with ".a" or ".o" and track it.  That does not
however mean that there can be no project and/or environment that validly
wants to track files with ".o" suffix (isn't it the case that windows shop
use ".obj" for object files and ".o" suffix do not have any particular
meaning to them?)  By placing "*.o" to tool-wide ignore file, your version
of git is making life for participants in such a project harder because
they can now easily forget to add a newly created "*.o" files (status
won't show them).  The tool should be extremely conservative not to
encourage such mistakes.

The best place to express such a project wide policy (e.g. "in this
project, '*.o' files will never, or rarely if ever, be tracked and we
expect our developers to appreciate not seeing them in status output by
default") is a tracked .gitignore file.

I earlier said that "*~" should not be in project-wide .gitignore file
because use of Emacs vs vi is a matter of personal taste, and Emacs
specific "*~" pattern does not belong to a project policy, just like
vim "*.swp" pattern doesn't.

But I think that reasoning is flawed.  The right criteria should not be
about "use of Emacs vs vi", but about "do we in this project ever want to
track files that match *~ or *.swp as legitimate contents".  If a project
expects not to have a tracked file whose name ends with ".swp", even if it
does _not_ mean to encourage use of vim over Emacs or any other editor, I
think it is fine to add such to its tracked .gitignore file for its
developer's benefit.