Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 10/03/2012 08:17 PM, Junio C Hamano wrote: >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html