Re: Gitignore matching "git add" wildcard prevents operation

[Marko Poutiainen <regs@sofistes.net>]

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?