On Thu, Jan 14, 2010 at 08:18:40PM +0200, Marko Poutiainen wrote: > It seems that that there is a bug related to how Git handles the add > command with wildcards if the wildcard also matches a file that is ignored. > > E.g (I activate the *.[ao] rule when editing .git/info/exclude): > > mep@Blackbird:~$ cd /tmp > mep@Blackbird:/tmp$ mkdir git > mep@Blackbird:/tmp$ cd git > mep@Blackbird:/tmp/git$ git init > Initialized empty Git repository in /tmp/git/.git/ > mep@Blackbird:/tmp/git$ nano -w .git/info/exclude > mep@Blackbird:/tmp/git$ touch a.o a.c a.h > mep@Blackbird:/tmp/git$ git add a.* > The following paths are ignored by one of your .gitignore files: > a.o > Use -f if you really want to add them. > fatal: no files added It's not a bug. That is working as designed. If "git add" encounters a problem with any of the files you gave it on the command line (and remember, the shell expands the wildcard, so git literally sees the three files on the command line) then it aborts the entire operation. Now whether that is useful behavior in this case, I don't know. If you were truly manually specifying the files, then it would probably not be a big deal to simply remove the offending file. But there is no way to use the shell wildcard and get the behavior you want (not even a "git add --really-ignore-my-ignores a.*"). I don't think it would be right to silently ignore them, because it may be the sign of an error. It could be downgraded to a warning, like: $ git add *.a warning: a.o is ignored, not adding The downside would be that somebody who really _did_ want to add such a file but forgot to use "-f" is going to be less likely to notice it, as the command does not barf. So maybe such behavior should be triggered with a command-line option. I dunno. -Peff -- 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