Re: [JGIT PATCH v2 19/24] Added the class AddRuleListFactory.
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- May 13, 2008, 01:29 UTC
- Message-ID
- <20080513012909.GG29038@spearce.org>
- In-Reply-To
- <1210623222-24908-20-git-send-email-florianskarten@web.de>
Florian Koeberle <florianskarten@web.de> wrote:
Show 9 quoted lines
> +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.
-- Shawn.