Re: Default exclude rules for Git

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 19, 2008, 15:46 UTC
Message-ID: <7v8wtouoit.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080919142211.GE10360@machine.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 18 quoted lines

> 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.