Skip to content
  • Jeff King's avatar
    attr: do not mark queried macros as unset · 7b95849b
    Jeff King authored and Junio C Hamano's avatar Junio C Hamano committed
    Since 60a12722 (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
    06a604e6 (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 60a12722 later refactored the macro code, it dropped maybe_real
    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
    
    It should be possible to salvage this optimization, but let's start with
    just removing the remnants. It hasn't been doing anything (except
    creating bugs) since 60a12722
    
    , and nobody seems to have noticed the
    performance regression. It's more important to fix the correctness
    problem clearly first.
    
    I've added two tests here. The second one actually shows off the bug.
    The test of "check-attr -a" is not strictly necessary, but we currently
    do not test attribute macros much, and the builtin "binary" not at all.
    So this increases our general test coverage, as well as making sure we
    didn't mess up this related case.
    
    Signed-off-by: default avatarJeff King <peff@peff.net>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    7b95849b