On Thu, Oct 4, 2012 at 1:17 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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"? It's basically what rsync describes: use ’**’ to match anything, including slashes. Reading rsync's man page again, I notice I missed two other rules related to **: - If the pattern contains a / (not counting a trailing /) or a "**", then it is matched against the full pathname, including any leading directories. If the pattern doesn't contain a / or a "**", then it is matched only against the final component of the filename. (Remember that the algorithm is applied recursively so "full filename" can actually be any portion of a path from the starting directory on down.) - A trailing "dir_name/***" will match both the directory (as if "dir_name/" had been specified) and everything in the directory (as if "dir_name/**" had been specified). This behavior was added in version 2.6.7. >From what you wrote, I think we'll go with the first rule. The second rule looks irrelevant to what git's doing. > 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 "x/y" too? (As opposed to "x/**/y" which does not) > 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? Yeah. That makes things easier to reason, though not exactly what we're having. -- Duy -- 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