Bug (or inconsistency) in git add

I couldn't find a bug tracker for Git, so here's my bug report.

Given a directory containing foo/bar/baz/blah.py and foo/bar/baz/blem.py, this command: 1) git add foo/**/*.py

produces no output, and adds no files.

This command: 2) git add /**.py

produces no output but adds all the files.

This command: 3) git add foo/**.py

produces an error and adds no files.

IMHO, "git add" should always produce an error message if no files matched the pathspec given. So case 1) should produce an error message.

git version 1.7.9.4 on Snow Leopard. (There doesn't seem to be a 1.7.10 at http://code.google.com/p/git-osx-installer/downloads/list?can=3)

If this is some weird bash shell behaviour, my apologies.

Steve

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

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...)

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

Steve Bennett <stevage@gmail.com> writes:

No, we don't.