On Tue, Oct 9, 2012 at 2:57 PM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
>> + - 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.

>> + - 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to