{"thread":{"id":"27925","subject":"\"git check-attr\" lists macros as being \"set\" -- feature or bug?","startedAt":"2011-07-26T12:10:11Z","lastAt":"2011-08-03T13:19:39Z","messageCount":4,"participants":["Michael Haggerty","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"172055","messageId":"4E2EAEA3.8000307@alum.mit.edu","threadId":"27925","inReplyTo":null,"subject":"\"git check-attr\" lists macros as being \"set\" -- feature or bug?","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-07-26T12:10:11Z","receivedAt":"2011-07-26T12:10:11Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"I am doing some work on git-check-attr, and I noticed something funny:\nIf a macro is used to set or clear attributes on a file in\n.gitattributes, then the name of the macro itself is listed as an\nattribute on that file.  Example:\n\n$ git init\nInitialized empty Git repository in /tmp/foo/.git/\n$ echo '[attr]notest !test' > .gitattributes\n$ echo 'no notest' >> .gitattributes\n\n# This is expected:\n$ git check-attr test -- no\nno: test: unspecified\n\n# This I found surprising:\n$ git check-attr notest -- no\nno: notest: set\n\nI don't see the correct behavior documented anywhere.  If this is\nconsidered a bug, then I offer to fix it.  If it is considered a\nfeature, then I offer to document it.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"172089","messageId":"20110726184756.GA520@sigill.intra.peff.net","threadId":"27925","inReplyTo":"4E2EAEA3.8000307@alum.mit.edu","subject":"Re: \"git check-attr\" lists macros as being \"set\" -- feature or bug?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-07-26T18:47:56Z","receivedAt":"2011-07-26T18:47:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 26, 2011 at 02:10:11PM +0200, Michael Haggerty wrote:\n\n> I am doing some work on git-check-attr, and I noticed something funny:\n> If a macro is used to set or clear attributes on a file in\n> .gitattributes, then the name of the macro itself is listed as an\n> attribute on that file.  Example:\n> \n> $ git init\n> Initialized empty Git repository in /tmp/foo/.git/\n> $ echo '[attr]notest !test' > .gitattributes\n> $ echo 'no notest' >> .gitattributes\n> \n> # This is expected:\n> $ git check-attr test -- no\n> no: test: unspecified\n> \n> # This I found surprising:\n> $ git check-attr notest -- no\n> no: notest: set\n> \n> I don't see the correct behavior documented anywhere.  If this is\n> considered a bug, then I offer to fix it.  If it is considered a\n> feature, then I offer to document it.\n\nI don't know the original rationale, but it seems like the only sane\nbehavior to me. If you care about the attributes that the macro is\nsetting, then you will test for those attributes, not caring whether\nthey came from a macro or not. The only time you will ask about the\nmacro itself is if you care whether the macro itself is set (though the\npoint of macros is that you don't care about them, but only the\nwell-known names of underlying attributes. So I think you would only\nwant to see this if you were doing some maintenance on your\ngitattributes files themselves, rather than simply reading their\nvalues).\n\nBut maybe I'm missing something.  Can you describe a use case where you\nwould want \"notest\" to be listed as \"unspecified\" in your example?\n\n-Peff\n"},{"id":"172093","messageId":"7vvcuoq13i.fsf@alter.siamese.dyndns.org","threadId":"27925","inReplyTo":"20110726184756.GA520@sigill.intra.peff.net","subject":"Re: \"git check-attr\" lists macros as being \"set\" -- feature or bug?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-26T19:43:45Z","receivedAt":"2011-07-26T19:43:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I don't know the original rationale, but it seems like the only sane\n> behavior to me.\n\nI know the original rationale, which was \"we didn't see any need to single\nout macros at all, and the code does what was the most straightforward\nfrom the point of view of the implementation\". If the resulting behaviour\nended up to be also sane, that would just mean that the implementation was\ngood ;-).\n\nI agree that showing the macros as set/unset just like elemental\nattributes is the only sane thing to do.  Majority of end users do not\ncare about how some attributes are macros (to cause other attributes to be\nset or unset), would set \"binary\" to their JPEG files, and would expect\nthe check-attr to say \"binary is set for this path\", without having to\nknow that \"binary\" affects \"diff\" and \"text\".\n\nWhen we say \"check-attr tells you if the named attribute is set\", do we\nsay \"but macros cannot be examined this way\" in the documentation?  If\nnot, I do not think we need any cluttering update.\n\nIt is a separate issue if macros should also be listed as the new feature\nthat lists all attributes given to a path. I tend to think the macro\nattributes as well as the other attributes they set should all be shown.\n"},{"id":"172754","messageId":"4E394AEB.7020006@alum.mit.edu","threadId":"27925","inReplyTo":"7vvcuoq13i.fsf@alter.siamese.dyndns.org","subject":"Re: \"git check-attr\" lists macros as being \"set\" -- feature or bug?","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-08-03T13:19:39Z","receivedAt":"2011-08-03T13:19:39Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 07/26/2011 09:43 PM, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n>> I don't know the original rationale, but it seems like the only sane\n>> behavior to me.\n\nI agree that the behavior is sane (and also convenient).\n\n> When we say \"check-attr tells you if the named attribute is set\", do we\n> say \"but macros cannot be examined this way\" in the documentation?  If\n> not, I do not think we need any cluttering update.\n\nI was confused by the following things:\n\n* The word \"macro\" in other contexts (e.g., C macros) typically refers\nto something that is fully replaced by its substitution text, leaving no\ntrace of the original macro or its name.\n\n* In gitattributes(5), the following misleading text:\n\n> ------------\n> *.jpg -text -diff\n> ------------\n>\n> but that may become cumbersome, when you have many attributes.  Using\n> attribute macros, you can specify groups of attributes set or unset at\n> the same time.  The system knows a built-in attribute macro, `binary`:\n>\n> ------------\n> *.jpg binary\n> ------------\n>\n> which is equivalent to the above.\n\nIt is *not* equivalent to the above, rather it is equivalent to\n\n*.jpg binary -text -diff\n\n(neglecting, of course, the recursive expansion of \"binary\").\n\nI will soon send a documentation patch.\n\n> It is a separate issue if macros should also be listed as the new feature\n> that lists all attributes given to a path. I tend to think the macro\n> attributes as well as the other attributes they set should all be shown.\n\nI agree.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}