Re: [RFC/PATCH] git-add: Don't exclude explicitly-specified tracked files

From: Greg Brockman <gdb@mit.edu>
Date: Aug 12, 2010, 03:19 UTC
Message-ID: <AANLkTi=uKceZZGLDP5+9DN8yBtWwt070ftWSc3J-Y63i@mail.gmail.com>
In-Reply-To: <7vaaosv8lt.fsf@alter.siamese.dyndns.org>

Show 11 quoted lines

> Here is the one that troubles me the most:
>
>  (6) git add dir/f*
>
> This _looks_ like very explicitly named from git's point of view, but from
> the end user's point of view it is not.  Depending on presense (or absense)
> of another file whose name begins with 'f' in the directory, the add will
> be either prevented or silently accepted.
>
> I am not sure what the best solution would be; I tend to think the current
> behaviour is slightly saner in the face of shell globbing.

I agree that case seems rather gray. But in what circumstances would you expect it to be a problem? I think only if the user has a tracked file with local changes that he or she does not wish to be committed. How common is it that a user will do this and expect gitignores to protect that file's changes I don't believe I've ever tried that in practice, but I also wouldn't trust gitignores to protect me from myself, as a careless 'git commit -a' would still commit my changes.

Perhaps one could add some syntax to .gitignore files that configures this behavior. I can come up with a proposal for something along those lines if you believe it would be useful. However, I don't have great use case for it, unless we also make 'git commit -a' and friends respect this configuration. (As an example, perhaps a line like +dir would mean that file should be excluded even if the user runs 'git add dir/file' while a line like dir would mean that 'git add dir/file' should succeed if dir/file is already tracked.)