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

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