Re: What's cooking in git.git (Oct 2012, #01; Tue, 2)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2012, 18:17 UTC
Message-ID: <7vbogj5sji.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8BGuoW6K_9vEgGrb2XC2bNtR=0jNRU3JQhsv7_diGQpbA@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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.

Show 7 quoted lines

> 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?