Re: [PATCH 8/8] Support "**" wildcard in .gitignore and .gitattributes

On Tue, Oct 9, 2012 at 2:57 PM, Michael Haggerty [off-list ref] wrote:

quoted

+ - A trailing "/**" matches everything inside. For example,
+   "abc/**" is equivalent to "`/abc/`".

It seems odd that you add a leading slash in this example.  I assume
that is because of the rule that a pattern containing a slash is
considered anchored at the current directory. But I find it confusing
because the addition of the leading slash is not part of the rule you
are trying to illustrate here, and is therefore a distraction.  I
suggest that you write either

- A trailing "/**" matches everything inside. For example,
  "/abc/**" is equivalent to "`/abc/`".

or

- A trailing "/**" matches everything inside. For example,
  "abc/**" is equivalent to "`abc/`" (which is also equivalent
  to "`/abc/`").

The tricky thing in .gitignore is that the last '/' alone does not
imply anchor. So "abc/" means match _directory_ abc anywhere in
worktree. So the former is probably better. I should also add a note
here (or in gitattributes.txt) about the difference between "/abc/*"
and "/abc/**". The former assigns attributes to all files directly
under abc (e.g. depth 1), the latter infinite depth.

quoted

+ - A slash followed by two consecutive asterisks then a slash
+   matches zero or more directories. For example, "`a/**/b`"
+   matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on.
+
+ - Consecutive asterisks otherwise are treated like normal
+   asterisk wildcards.
+

I don't like the last rule.  (1) This construct is superfluous; why
wouldn't the user just use a single asterisk?  (2) Allowing this
construct means that it could appear in .gitignore files, creating
unnecessary confusion: extrapolating from the other meanings of "**"
users would expect that it would somehow match slashes.  (3) It is
conceivable (though admittedly unlikely) that we might want to assign a
distinct meaning to this construct in the future, and accepting it now
as a different way to spell "*" would prevent such a change.

Perhaps this rule was intended for backwards compatibility?

We break backwards compatibility already. Existing "**/" or "/**"
patterns now behave differently.

I think it would be preferable to say that other uses of consecutive
asterisks are undefined, and probably make them trigger a warning.

Instead of undefined, we can reject the pattern as "broken". I have to
check how fnmatch/wildmatch deals with broken patterns (it must do).
If it returns a different code for broken patterns, then we can warn
users, which is not limited in just "**" breakage.
-- 
Duy