Nguyen Thai Ngoc Duy <> writes:

> There's an interesting case: "**foo". According to our rules, that
> pattern does not contain slashes therefore is basename match. But some
> might find that confusing because "**" can match slashes,...

By "our rules", if you mean "if a pattern has slash, it is anchored",
that obviously need to be updated with this series, if "**" is meant
to match multiple hierarchies.
> I think the latter makes more sense. When users put "**" they expect
> to match some slashes. But that may call for a refactoring in
> path_matches() in attr.c. Putting strstr(pattern, "**") in that
> matching function may increase overhead unnecessarily.
> The third option is just die() and let users decide either "*foo",
> "**/foo" or "/**foo", never "**foo".

For the double-star at the beginning, you should just turn it into "**/"
if it is not followed by a slash internally, I think.

What is the semantics of ** in the first place?  Is it described to
a reasonable level of detail in the documentation updates?  For
example does "**foo" match "afoo", "a/b/foo", "a/bfoo", "a/foo/b",
"a/bfoo/c"?  Does "x**y" match "xy", "xay", "xa/by", "x/a/y"?

I am guessing that the only sensible definition is that "**"
requires anything that comes before it (if exists) is at a proper
hierarchy boundary, and anything matches it is also at a proper
hierarchy boundary, so "x**y" matches "x/a/y" and not "xy", "xay",
nor "xa/by" in the above example.  If "x**y" can match "xy" or "xay"
(or "**foo" can match "afoo"), it would be unreasonable to say it
implies the pattern is anchored at any level, no?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to