Re: [JGIT PATCH v2 19/24] Added the class AddRuleListFactory.

Robin Rosenberg [off-list ref] wrote:

tisdagen den 13 maj 2008 13.24.56 skrev Florian Köberle:

quoted

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.