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

[Greg Brockman <gdb@MIT.EDU>]

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