Nguyễn Thái Ngọc Duy <[email protected]> writes:
> "**" is adjusted to only be effective when surrounded by slashes, in
> 40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
> the commit did it wrong:
>
> 1. when it checks for "the preceding slash unless ** is at the
> beginning", it compares to wrong pointer. It should have compared
> to the beginning of the pattern, not the text.
So should
git ls-files '**/Makefile'
list the Makefile at the top-level of the repository (I think it
should)?
But that does not seem to be working.
I think the callpath goes like this:
match_pathspec()
-> match_one()
-> fnmatch_icase()
-> fnmatch()
-> wildmatch()
and the problem is that the fnmatch_icase() call made by match_one()
always passes 0 as the value for flags. Without WM_PATHNAME,
however, the underlying dowild() does not honor the "**/" magic.
We obviously do not want to set FNM_PATHNAME when we are not
substituting fnmatch() with wildmatch(), but I wonder if it may make
sense to unconditionally use WM_PATHNAME semantics when we build the
system with USE_WILDMATCH and calling wildmatch() in this codepath.
Users can always use "*/**/*" in place of "*" in their patterns
where they want to ignore directory boundaries.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
