Nguyễn Thái Ngọc Duy  <pclo...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to