Florian Koeberle <florianskarten@xxxxxx> 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.
--
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
