Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

quoted text
>  2011/1/4 Marcin Wiśnicki <mwisnicki@gmail.com>:
>  > I think that for the time being at least the manual page must change to
>  > reflect reality.
>
>  Looks like changes will be more than just a few lines because path_matches()
>  needs to learn about directories (iow less likely to get fixed right away).
>  So, yes, good idea.

Not really.  I'd rather see a handful of test cases added to t0003 to help
interested parties to see what is broken and what is not.

Quoting from Marcin's other message, assuming that "Patterns" are stored
in either .gitattributes at the top level or .git/info/attributes:

quoted text
> Example for file: d1/d2/f1.c
> 
> Patterns that match:
>   *.c

No slashes, so it should match anywhere (correct).

quoted text
>   d1/d2/*

With slashes, so this is anchored at the toplevel of the working tree, and
the path should match (correct).

quoted text
>   /d1/d2/*

The same as above;, the leading '/' is only to make it explicit that it is
anchored at the level

quoted text
>   */d2/*

Should match.

quoted text
>   */*/*

Should match.

quoted text
> Patterns that do not match but should:
>   d2/*

This shouldn't match unless it appears in d1/.gitattributes.

The presense of '/' makes the pattern anchored to the directory it appear
in, and .git/info/attributes is taken as being at the top level.

quoted text
>   d2/
>   d2

These shouldn't for the same reason.

quoted text
>   d1/d2
>   /d1/d2

We somehow don't do leading path match like we do for gitignore, but I do
not think this was intended.  My gut feeling is that these should match.

The thinking back, when we wrote the code, could have been that, unlike
gitignore that maintains only one bit (either "ignored" or "not"),
attributes are richer and giving the same attribute (say "whitespace
checking criteria") to files inside a directory and the containing
directory itself was nonsensical.  But if that was the reason, it is
faulty, as we do not track directories anyway.

Wouldn't it be sufficient to teach attr.c:path_matches() that a pattern
could also match with leading path?  That would automatically cover the
case where a pattern is terminated with a slash, as pattern "d/e/" would
never match path "d/e" but does match "d/e/f"?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html