Re: Fwd: Add git ignore as builtin

From: Jeff King <peff@peff.net>
Date: Nov 17, 2014, 20:59 UTC
Message-ID: <20141117205957.GB15880@peff.net>
In-Reply-To: <loom.20141117T010932-213@post.gmane.org>

On Mon, Nov 17, 2014 at 12:12:25AM +0000, Ryan Jacobs wrote:

Show 8 quoted lines

> Alberto Fanjul Alonso <albertofanjul <at> gmail.com> writes:
> 
> 
> > git ignore <whatever> adds <whatever> to .git/info/exclude
> 
> This should be "git exclude" not "git ignore".
> Difference between the two: http://stackoverflow.com/questions/10066749/git-
> excludes-vs-ignores

I am not sure that the name difference is all that meaningful. Yes, we call the repo-wide file .git/info/exclude and the in-tree ones .gitignore, but I do not know if the distinction is more than historical accident.

> I'd second the notion of a "git ignore", however it would have to modify the 
> `.gitignore` not `.git/info/exclude`.

And I think this is a good reason why we do not have a "git ignore" tool to write such things. If I say "git ignore foo" should it go into .git/info/exclude or .gitignore? If the latter, should it be "foo" to match everywhere, or "/foo" to match only the single path at the root? If the file is "subdir/foo", should it go as "/subdir/foo" into the top-level ".gitignore", or as "foo" into "subdir/.gitignore"? If you ignore "foo.o" and "bar.o", should we suggest that you ignore "*.o" instead?

Trying to accomodate all of those possibilities in a command-line tool is hard, and probably counter-productive. We already have a simple domain-specific language for specifying .gitignore files. You can just try to cover a common case, like "always put the full slash-prefixed path into the top-level .gitignore". But then I wonder if "git ignore" is really adding much value, as it is just a thin wrapper around "echo".

-Peff

PS The more interesting case to automate (to me, anyway) is _checking_
   paths against the hand-written .gitignore rules, which is complicated
   to do by hand.  You can do that already with "git check-ignore".