Re: Gitignore matching "git add" wildcard prevents operation

[Jeff King <peff@peff.net>]

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