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