Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> wrote:
> tisdagen den 13 maj 2008 13.24.56 skrev Florian Köberle:
> >
> > Still I think that the behavior of git-add is strange:
> > For example, if you want to add the following file:
> > a/b/c/test.txt
> > Then I can do this with "a/\*.txt" or "a/b\*.txt" but not with
> > "a/\*/c/test.txt"
...
> Correctness is very important. Obviously we will slip bugs trough, but
> not intentionally in a part where legacy behaviour may play an important
> role. With these options available I'd select number 2.
>
> I think your observations are interesting, especially the one you make
> here about a/*/c/test.txt not matching because I don't see from the git
> add manual why it shouldn't. I does not look like a recent git bug either.
Wow. The behavior of git-add makes _no_ sense to me.
$ git init
$ mkdir -p a/b/c; touch a/b/c/test.txt
$ find a
a
a/b
a/b/c
a/b/c/test.txt
$ git add 'a/*/test.txt'
fatal: pathspec 'a/*/test.txt' did not match any files
(sure, ok, even my shell agrees)
$ git add 'a/*/c/test.txt'
fatal: pathspec 'a/*/c/test.txt' did not match any files
$ ls a/*/c/test.txt
a/b/c/test.txt
(hmm, now my shell says otherwise)
$ git add 'a/b*/c/test.txt'
fatal: pathspec 'a/b*/c/test.txt' did not match any files
$ ls a/b*/c/test.txt
a/b/c/test.txt
(also odd)
This last case does match with fnmatch:
$ cat fnmatch.c
#include <fnmatch.h>
#include <stdio.h>
int main (int argc, char *argv[]) {
const char *name = argv[1];
const char *patt = argv[2];
printf("\"%s\" matches \"%s\" = %d\n",
name, patt,
fnmatch(patt, name, 0));
return 0;
}
$ gcc -o fnmatch fnmatch.c
$ ./fnmatch a/b/c/test.txt 'a/b*/c/test.txt'
"a/b/c/test.txt" matches "a/b*/c/test.txt" = 0
So I find it odd that git-add does not match this name, but fnmatch
does. I suspect the problem here is git-add has pruned away the
subdirectory "a/b" and did not enter into it, so the pattern was
never even given a chance to look at test.txt. This sounds like
a bug to me in git's working directory filter.
Even if Linus says matching names incorrectly is not a bug, I'm
not sure its an implementation detail we should mirror in jgit.
Where does that leave us? I'm not sure. But treating git-add as
a black box and replicating its behavior looks loony to me right now.
--
Shawn.
--
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
