Re: [PATCH] ref-filter: handle nested tags in --points-at option

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 5, 2023, 20:15 UTC
Message-ID: <xmqq8rbuyv14.fsf@gitster.g>
In-Reply-To: <ZKW7bjVHeEOnza62@thinkpad.fritz.box>

Jan Klötzke <jan@kloetzke.net> writes:

Show 13 quoted lines

> Am Wed, Jul 05, 2023 at 10:16:17AM -0700 schrieb Junio C Hamano:
>> Interesting.  Right now, if I create a 'direct' tag that points
>> directly at HEAD, and then create an 'indirect' tag that points at
>> 'direct', i.e.
>> 
>>     $ git tag -a -m 'a direct tag to HEAD' direct HEAD
>>     $ git tag -a -m 'an indirect tag' indirect direct
>> 
>> I would get a piece of advice message that encourages to correct the
>> mistake with "git tag -f indirect direct^{}".
> ...
> But as most git commands can handle nested tags they should better be
> supported consistently IMHO.

Do they? Most git commands handle nested tags in only one way: by fully peeling. "git checkout --detach indirect" in the above scenario would handle nested tag "indirect" well, but it is done by making "direct" tag inaccessible when the only thing you have is the "indirect" tag. For example, you cannot create another "indirect" tag that points at "direct" tag with "git tag", with

    $ git tag -a -m 'another indirect' indirect-2 indirect^{}

The resulting tag will be another direct tag to the underlying commit, and not a tag of the "direct" tag.

In that sense, --points-at we currently have that only peels once is inconsistent with the others, but --points-at that peels repeatedly and allows the intermediate steps to match is also behaving inconsistently relative to most git commands.

Combined with the fact that we seem to discourage such an indirect tag, we should either:

 (1) declare that indirect tags are not useful, turn the warning
     advice.nestedTag into a stronger error, devise appropriate
     transition plan to get rid of nested tag (e.g. eventually
     making it impossible to use "git tag" to create such a tag and
     let "git fsck" complain about them), and perhaps change
     "--points-at" to take only the fully peeled object into account
     so that optimization based on packed-refs becomes possible.  Or

 (2) declare that indirect tags are useful thing to support, tone
     down the advice.nestedTag message, and enhance the support of
     indirect tags, starting with this "--points-at" enhancement.

I am inclined to support (2), but then a consistent support would need to eventually include a "peel only a single level" primitive as well. That would be the first step to allow "most git commands" to support nested tags well, as they currently do not.

Thanks for working on this. Let's queue it, together will Peff's patches (which I haven't studied fully yet).