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

["Shawn O. Pearce" <spearce@spearce.org>]

Robin Rosenberg <robin.rosenberg.lists@dewire.com> 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.