{"thread":{"id":"26188","subject":"[PATCH] gitattributes.txt: mention exceptions to gitignore rules","startedAt":"2011-01-04T13:31:55Z","lastAt":"2011-01-04T21:17:26Z","messageCount":5,"participants":["Nguyễn Thái Ngọc Duy","Michael J Gruber","Marcin Wiśnicki","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"158888","messageId":"1294147915-1475-1-git-send-email-pclouds@gmail.com","threadId":"26188","inReplyTo":"iftvu6@dough.gmane.org","subject":"[PATCH] gitattributes.txt: mention exceptions to gitignore rules","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-01-04T13:31:55Z","receivedAt":"2011-01-04T13:31:55Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"gitattr and .gitignore are supposed to use the same rules for matching\npatterns. Unfortunately it's not exactly the same in reality. Mention\nthe differences so users won't be surprised, until gitattr gets\nupdates.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n 2011/1/4 Marcin Wiśnicki :\n > I think that for the time being at least the manual page must change to\n > reflect reality.\n\n Looks like changes will be more than just a few lines because path_matches()\n needs to learn about directories (iow less likely to get fixed right away).\n So, yes, good idea.\n\n I skimmed through excluded_from_list() (gitignore) and path_matches (gitattr).\n Seems no other differences.\n\n Documentation/gitattributes.txt | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\nindex 5a7f936..cfaf107 100644\n--- a/Documentation/gitattributes.txt\n+++ b/Documentation/gitattributes.txt\n@@ -56,6 +56,7 @@ When more than one pattern matches the path, a later line\n overrides an earlier line. This overriding is done per\n attribute. The rules how the pattern matches paths are the\n same as in `.gitignore` files; see linkgit:gitignore[5].\n+However patterns that end with a slash is not supported.\n \n When deciding what attributes are assigned to a path, git\n consults `$GIT_DIR/info/attributes` file (which has the highest\n-- \n1.7.3.4.878.g439c7\n"},{"id":"158892","messageId":"4D2333C0.702@drmicha.warpmail.net","threadId":"26188","inReplyTo":"1294147915-1475-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-01-04T14:50:40Z","receivedAt":"2011-01-04T14:50:40Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyễn Thái Ngọc Duy venit, vidit, dixit 04.01.2011 14:31:\n> gitattr and .gitignore are supposed to use the same rules for matching\n> patterns. Unfortunately it's not exactly the same in reality. Mention\n> the differences so users won't be surprised, until gitattr gets\n> updates.\n> \n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> 2011/1/4 Marcin Wiśnicki :\n> > I think that for the time being at least the manual page must change to\n> > reflect reality.\n> \n> Looks like changes will be more than just a few lines because path_matches()\n> needs to learn about directories (iow less likely to get fixed right away).\n> So, yes, good idea.\n> \n> I skimmed through excluded_from_list() (gitignore) and path_matches (gitattr).\n> Seems no other differences.\n> \n> Documentation/gitattributes.txt | 1 +\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n> \n> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt\n> index 5a7f936..cfaf107 100644\n> --- a/Documentation/gitattributes.txt\n> +++ b/Documentation/gitattributes.txt\n> @@ -56,6 +56,7 @@ When more than one pattern matches the path, a later line\n> overrides an earlier line. This overriding is done per\n> attribute. The rules how the pattern matches paths are the\n> same as in `.gitignore` files; see linkgit:gitignore[5].\n> +However patterns that end with a slash is not supported.\n\n+However, patterns terminated by a slash are not supported.\n\n> \n> When deciding what attributes are assigned to a path, git\n> consults `$GIT_DIR/info/attributes` file (which has the highest\n\nCheers,\nMichael\n"},{"id":"158893","messageId":"ifvf22$g68$1@dough.gmane.org","threadId":"26188","inReplyTo":"1294147915-1475-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules","fromName":"Marcin Wiśnicki","fromEmail":"mwisnicki@gmail.com","sentAt":"2011-01-04T15:40:50Z","receivedAt":"2011-01-04T15:40:50Z","isPatch":true,"sender":{"key":"mwisnicki@gmail.com","avatar":"https://gravatar.com/avatar/6bc6cce46e549217fe39b05ac03acb4f5755154d6752ff65b580783365ad3e50?d=mp&s=160"},"body":"On Tue, 04 Jan 2011 20:31:55 +0700, Nguyễn Thái Ngọc Duy wrote:\n\n> gitattr and .gitignore are supposed to use the same rules for matching\n> patterns. Unfortunately it's not exactly the same in reality. Mention\n> the differences so users won't be surprised, until gitattr gets updates.\n> \n> \n> diff --git a/Documentation/gitattributes.txt\n> b/Documentation/gitattributes.txt index 5a7f936..cfaf107 100644\n> --- a/Documentation/gitattributes.txt +++\n> b/Documentation/gitattributes.txt @@ -56,6 +56,7 @@ When more than one\n> pattern matches the path, a later line\n> overrides an earlier line. This overriding is done per attribute. The\n> rules how the pattern matches paths are the same as in `.gitignore`\n> files; see linkgit:gitignore[5].\n> +However patterns that end with a slash is not supported.\n> \n\nI'm afraid that is not all. The rules I've inferred:\n\n 1. No pattern will match directory tree.\n 2. It is only possible to match on path components.\n 3. If pattern contains slash it is treated as absolute.\n\nExample for file: d1/d2/f1.c\n\nPatterns that match:\n *.c\n d1/d2/*\n /d1/d2/*\n */d2/*\n */*/*\n\nPatterns that do not match but should:\n d2/*\n d2/\n d2\n d1/d2\n /d1/d2\n"},{"id":"158903","messageId":"7vwrmkfphh.fsf@alter.siamese.dyndns.org","threadId":"26188","inReplyTo":"1294147915-1475-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-04T19:17:14Z","receivedAt":"2011-01-04T19:17:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> 2011/1/4 Marcin Wiśnicki :\n> > I think that for the time being at least the manual page must change to\n> > reflect reality.\n>\n> Looks like changes will be more than just a few lines because path_matches()\n> needs to learn about directories (iow less likely to get fixed right away).\n> So, yes, good idea.\n\nNot really. I'd rather see a handful of test cases added to t0003 to help\ninterested parties to see what is broken and what is not.\n\nQuoting from Marcin's other message, assuming that \"Patterns\" are stored\nin either .gitattributes at the top level or .git/info/attributes:\n\n> Example for file: d1/d2/f1.c\n> \n> Patterns that match:\n> *.c\n\nNo slashes, so it should match anywhere (correct).\n\n> d1/d2/*\n\nWith slashes, so this is anchored at the toplevel of the working tree, and\nthe path should match (correct).\n\n> /d1/d2/*\n\nThe same as above;, the leading '/' is only to make it explicit that it is\nanchored at the level\n\n> */d2/*\n\nShould match.\n\n> */*/*\n\nShould match.\n\n> Patterns that do not match but should:\n> d2/*\n\nThis shouldn't match unless it appears in d1/.gitattributes.\n\nThe presense of '/' makes the pattern anchored to the directory it appear\nin, and .git/info/attributes is taken as being at the top level.\n\n> d2/\n> d2\n\nThese shouldn't for the same reason.\n\n> d1/d2\n> /d1/d2\n\nWe somehow don't do leading path match like we do for gitignore, but I do\nnot think this was intended. My gut feeling is that these should match.\n\nThe thinking back, when we wrote the code, could have been that, unlike\ngitignore that maintains only one bit (either \"ignored\" or \"not\"),\nattributes are richer and giving the same attribute (say \"whitespace\nchecking criteria\") to files inside a directory and the containing\ndirectory itself was nonsensical. But if that was the reason, it is\nfaulty, as we do not track directories anyway.\n\nWouldn't it be sufficient to teach attr.c:path_matches() that a pattern\ncould also match with leading path? That would automatically cover the\ncase where a pattern is terminated with a slash, as pattern \"d/e/\" would\nnever match path \"d/e\" but does match \"d/e/f\"?\n"},{"id":"158915","messageId":"ig02p5$kh3$1@dough.gmane.org","threadId":"26188","inReplyTo":"7vwrmkfphh.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] gitattributes.txt: mention exceptions to gitignore rules","fromName":"Marcin Wiśnicki","fromEmail":"mwisnicki@gmail.com","sentAt":"2011-01-04T21:17:26Z","receivedAt":"2011-01-04T21:17:26Z","isPatch":true,"sender":{"key":"mwisnicki@gmail.com","avatar":"https://gravatar.com/avatar/6bc6cce46e549217fe39b05ac03acb4f5755154d6752ff65b580783365ad3e50?d=mp&s=160"},"body":"On Tue, 04 Jan 2011 11:17:14 -0800, Junio C Hamano wrote:\n\n>> Patterns that do not match but should:\n>> d2/*\n> \n> This shouldn't match unless it appears in d1/.gitattributes.\n> \n> The presense of '/' makes the pattern anchored to the directory it\n> appear in, and .git/info/attributes is taken as being at the top level.\n> \n\nAfter more carefully re-reading gitignore(5) I think that now I get it.\n\nI presume that is is not possible to match certain pattern occurring \n*anywhere* in the path.\n\nWould it be possible to extend pattern format to include double-star \nwildcard that matches anything including slashes ?\n\nLike: **/whatever/**\n\nMany tools (in java at least) and libraries support such extension to \nglobs. Unfortunately standard fnmatch(3) that's used by git is not one of \nthem, but glibc's implementation looks portable and self-contained so it \ncould be included and modified.\n\n\n>> d2/\n>> d2\n> \n> These shouldn't for the same reason.\n> \n>> d1/d2\n>> /d1/d2\n> \n> We somehow don't do leading path match like we do for gitignore, but I\n> do not think this was intended. My gut feeling is that these should\n> match.\n> \n> The thinking back, when we wrote the code, could have been that, unlike\n> gitignore that maintains only one bit (either \"ignored\" or \"not\"),\n> attributes are richer and giving the same attribute (say \"whitespace\n> checking criteria\") to files inside a directory and the containing\n> directory itself was nonsensical. But if that was the reason, it is\n> faulty, as we do not track directories anyway.\n> \n> Wouldn't it be sufficient to teach attr.c:path_matches() that a pattern\n> could also match with leading path? That would automatically cover the\n> case where a pattern is terminated with a slash, as pattern \"d/e/\" would\n> never match path \"d/e\" but does match \"d/e/f\"?\n"}]}