Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > So we could invent that as this series currently does with: > > git check-attrs --revision <rev> <attr>... <path>... > > Or, as I suggested: > > git check-attr [<rev>:]<attr>... -- <path>... What does <rev>:<attr> really mean? As the syntax for the proposed feature, I do not think it makes much sense. For example: $ git check-attr HEAD:text HEAD^:text -- README.txt - With which README.txt are we checking the attribute? The one taken from HEAD or HEAD^ or the index or the working tree? - When we say "README.txt has the text attribute", how does the user tell which "text" applies to the path? From HEAD? From HEAD^? - Does the same attribute 'text' have different meaning when coming from two different tree-ish? Compared to that at least the proposed one makes it fairly clear that we are talking about things in a single tree-ish consistently.
