Re: [PATCH v3 0/2] check-attr: add support to work with revisions

From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Karthik Nayak <karthik.188@gmail.com>,
	git@vger.kernel.org, toon@iotcl.com
Subject: Re: [PATCH v3 0/2] check-attr: add support to work with revisions
Date: Sat, 17 Dec 2022 07:38:08 +0900	[thread overview]
Message-ID: <xmqq7cyrm0tr.fsf@gitster.g> (raw)
In-Reply-To: <221216.86k02r1fcl.gmgdl@evledraar.gmail.com> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Fri, 16 Dec 2022 17:17:48 +0100")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.