Re: Bug (or inconsistency) in git add

From: Steve Bennett <stevage@gmail.com>
Date: Apr 30, 2012, 06:46 UTC
Message-ID: <CADJEhEXtDZGav1Y5epZQ69NWptyVyPC1hmN6=YaNYrg3vYmBqg@mail.gmail.com>
In-Reply-To: <CAA5Ydx9h6o=uppRk5zc9V4z1S831KGVRBzTw9oMqDjY34-noOw@mail.gmail.com>

On 30 April 2012 16:23, Victor Engmark <victor.engmark@gmail.com> wrote:

Show 5 quoted lines

> I can't answer for the absence of an error when no files are added, but
> globbing (resolving * in paths) is done by the shell, not by git. To verify
> a glob, just echo it:
>
> echo foo/**/*.py

Yes, it appears that the two cases are treated differently:
1) foo/**/*.py:  the shell expands the **, and interprets it the same
as "*",  so foo/**/*.py means any python file exactly one directory
deeper than foo
2) /**.py: the shell ignores this and passes it straight to Git.

So I guess the missing error message I reported originally is logically correct in a kind of convoluted way: the ** is actually matching real files (just not the ones you expected) and they don't have any changes, so you don't get any output.

(Whether or not it makes sense for Git to produce identical output in the case of both adding files with changes, and doing nothing at all, is a debate I probably shouldn't start...)

> If you want to add recursively, you'll need to enable the special behavior
> for double stars:
>
> shopt -s globstar

Looks like I need a newer version of Bash.

In any case, it looks like Git does support some ** globbing natively. I'm curious about the rules for that. They don't seem to be documented in the git man page (http://schacon.github.com/git/user-manual.html).

Steve