Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

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

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:54:56

On Thu, Oct 4, 2012 at 1:17 AM, Junio C Hamano [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help