On Tue, Jul 26, 2011 at 02:10:11PM +0200, Michael Haggerty wrote: > I am doing some work on git-check-attr, and I noticed something funny: > If a macro is used to set or clear attributes on a file in > .gitattributes, then the name of the macro itself is listed as an > attribute on that file. Example: > > $ git init > Initialized empty Git repository in /tmp/foo/.git/ > $ echo '[attr]notest !test' > .gitattributes > $ echo 'no notest' >> .gitattributes > > # This is expected: > $ git check-attr test -- no > no: test: unspecified > > # This I found surprising: > $ git check-attr notest -- no > no: notest: set > > I don't see the correct behavior documented anywhere. If this is > considered a bug, then I offer to fix it. If it is considered a > feature, then I offer to document it. I don't know the original rationale, but it seems like the only sane behavior to me. If you care about the attributes that the macro is setting, then you will test for those attributes, not caring whether they came from a macro or not. The only time you will ask about the macro itself is if you care whether the macro itself is set (though the point of macros is that you don't care about them, but only the well-known names of underlying attributes. So I think you would only want to see this if you were doing some maintenance on your gitattributes files themselves, rather than simply reading their values). But maybe I'm missing something. Can you describe a use case where you would want "notest" to be listed as "unspecified" in your example? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html