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

> Florian Koeberle <florianskarten@web.de> wrote:
>> +class AddRuleListFactory {
>> +	/*
>> +	 * The add command of git 1.5.2.5 behaves a little bit stange: "git add
>> +	 * a/\*z" adds the file "a/b/xyz" but "git add a/x\*" does not.
>> +	 * 
>> +	 * The first is parsed as pattern "*z" for whole directory tree "a". The
>> +	 * second is parsed as an path.
>> +	 * 
>> +	 */
> 
> Its not strange.  C Git expands each file path to its _full_ path
> and stores that into a buffer, then runs fnmatch() for each pattern
> on the buffer.  If fnmatch() succeeds the path is added to the index.
> 
> In the case above we are running a match of "a/\*.z" against
> "a/b/xyz" and that passes.  Or we run "a/x\*" on "a/b/xyz" and it
> fails as the sequence of characters "a/x" does not appear in the
> string "a/b".
> 
> You are running into this odd corner case because you are not
> treating the pattern passed as something that matches against the
> entire path.  This is one reason why TreeFilter's use the entire
> path when they process an entry for inclusion or exclusion, and why
> TreeWalk has each AbstractTreeIterator append the current entry name
> onto the end of the current path buffer, so we can always examine
> the full path from the root of the repository/working directory.
> 
> Trying to avoid the full path in classes like ComplexFilePattern
> is why you are running into this corner case here, and must now do
> extra contortions to somewhat match the behavior of C Git.
> 
> At this point I think most of the rules package is overcomplicated
> and overoptimized, and yet doesn't actually quite match the behavior
> of C Git.
>