> 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.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html