Re: "git check-attr" lists macros as being "set" -- feature or bug?

[Jeff King <peff@peff.net>]

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