Jeff King wrote: > 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. Well, it then the interface just isn't consistent, because if that's the reason, then why does $git add . then work in this case? . is still just a type of wildcard, so it fail in a similar way, shouldn't it? Your idea of giving a warning is good as is the command-line option. In any case, in my opinion this feature can make some operations more complex than they should be. For instance, in my example I would have to separately do git add to both files. What if there are more than two files to add and I get this error every time I try to add the files? -- 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