git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] attr: do not mark queried macros as unset

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 22, 2019, 21:48 UTC
Message-ID
<xmqqlg3ce545.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20190118213458.GB28808@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 50 quoted lines
> On Fri, Jan 18, 2019 at 11:58:01AM -0500, Jeff King wrote:
>
>> Now, on to the actual bug. The simplest reproduction is:
>> 
>>   (echo "[attr]foo bar"; echo "* foo") >.gitattributes
>>   git check-attr foo file
>
> Actually, even simpler is to just "binary", which is pre-defined as a
> macro. :)
>
>> which should report "foo" as set. This bisects to 60a12722ac (attr:
>> remove maybe-real, maybe-macro from git_attr, 2017-01-27), and it seems
>> like an unintentional regression there. I haven't yet poked into that
>> commit to see what the fix will look like.
>
> So here's the fix I came up with. +cc Duy, as this is really tangled
> with his older 06a604e670.
>
> -- >8 --
> Subject: [PATCH] attr: do not mark queried macros as unset
>
> Since 60a12722ac (attr: remove maybe-real, maybe-macro from git_attr,
> 2017-01-27), we will always mark an attribute macro (e.g., "binary")
> that is specifically queried for as "unspecified", even though listing
> _all_ attributes would display it at set. E.g.:
>
>   $ echo "* binary" >.gitattributes
>
>   $ git check-attr -a file
>   file: binary: set
>   file: diff: unset
>   file: merge: unset
>   file: text: unset
>
>   $ git check-attr binary file
>   file: binary: unspecified
>
> The problem stems from an incorrect conversion of the optimization from
> 06a604e670 (attr: avoid heavy work when we know the specified attr is
> not defined, 2014-12-28). There we tried in collect_some_attrs() to
> avoid even looking at the attr_stack when the user has asked for "foo"
> and we know that "foo" did not ever appear in any .gitattributes file.
>
> It used a flag "maybe_real" in each attribute struct, where "real" meant
> that the attribute appeared in an actual file (we have to make this
> distinction because we also create an attribute struct for any names
> that are being queried). But as explained in that commit message, the
> meaning of "real" was tangled with some special cases around macros.
>
> When 06a604e670 later refactored the macro code, it dropped maybe_real
I think 60a12722ac is what you meant here.
Show 10 quoted lines
> entirely. This missed the fact that "maybe_real" could be unset for two
> reasons: because of a macro, or because it was never found during
> parsing. This had two results:
>
>   - the optimization in collect_some_attrs() ceased doing anything
>     meaningful, since it no longer kept track of "was it found during
>     parsing"
>
>   - worse, it actually kicked in when the caller _did_ ask about a macro
>     by name, causing us to mark it as unspecified
Previous: Duy NguyenNext: Jeff King
Message 14 of 15 in “Change on check-attr behavior”
  1. Sérgio PeixotoJan 17, 2019
  2. Jeff KingJan 17, 2019
  3. Sérgio PeixotoJan 18, 2019
  4. Jeff KingJan 18, 2019
  5. attr: do not mark queried macros as unsetJeff King, Jan 18, 2019
  6. Jeff KingJan 18, 2019
  7. Stefan BellerJan 18, 2019
  8. Jeff KingJan 22, 2019
  9. Duy NguyenJan 22, 2019
  10. Junio C HamanoJan 22, 2019
  11. Duy NguyenJan 21, 2019
  12. Jeff KingJan 22, 2019
  13. Duy NguyenJan 22, 2019
  14. Junio C HamanoJan 22, 2019
  15. Jeff KingJan 23, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.