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

Michael Haggerty [off-list ref] writes:

On 10/03/2012 08:17 PM, Junio C Hamano wrote:

quoted

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?

Given that there is no obvious interpretation for what a construct like
"x**y" would mean, and many plausible guesses (most of which sound
rather useless), I suggest that we forbid it.  This will make the
feature easier to explain and make .gitignore files that use it easier
to understand.

I think that 98% of the usefulness of "**" would be in constructs where
it replaces a proper part of the pathname, like "**/SOMETHING" or
"SOMETHING/**/SOMETHING"...

I think it is a good way to go in the longer term, if we all agree
that "**" matching anything does not give us a useful semantics
[*1*].

Is it something we can easily get by simple patch into the wildmatch
code?  I'd hate to see us parsing the input and validating it before
passing it to the library, as we will surely botch the quoting or
something while doing so.

When we require "x/**/y", I think we still want it to match "x/y".
Do people agree, or are there good reasons to require at least one
level between x and y for such a pattern?  Assuming that we do want
to match "x/y" with "x/**/y", I suspect that "'**' matches anything
including a slash" would not give us that semantics. Is it something
we can easily fix in the wildmatch code?


[Footnote]

*1* The message you are responding to was written in a somewhat
provocative way on purpose so that people who like the way rsync
matches "**" can vocally object. I would like to see arguments from
the both sides to see if it makes sense.

On Thu, Oct 04, 2012 at 09:39:02AM -0700, Junio C Hamano wrote:

Assuming that we do want to match "x/y" with "x/**/y", I suspect
that "'**' matches anything including a slash" would not give us
that semantics. Is it something we can easily fix in the wildmatch
code?

Something like this may suffice. Lightly tested with "git add -n".
Reading the code, I think we can even distinguish "match zero or more
directories" and "match one or more directories" with "/**/" and maybe
"/***/". Right now **, ***, ****... are the same. So are /**/, /***/,
/****/...

-- 8< --

diff --git a/wildmatch.c b/wildmatch.c
index f153f8a..81eadc8 100644
--- a/wildmatch.c
+++ b/wildmatch.c

@@ -98,8 +98,12 @@ static int dowild(const uchar *p, const uchar *text,
 	    continue;
 	  case '*':
 	    if (*++p == '*') {
+		int slashstarstar = p[-2] == '/';
 		while (*++p == '*') {}
 		special = TRUE;
+		if (slashstarstar && *p == '/' &&
+		    dowild(p + 1, text, a, force_lower_case) == TRUE)
+		    return TRUE;
 	    } else
 		special = FALSE;
 	    if (*p == '\0') {
-- 8< --

-- 
Duy