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

[Junio C Hamano <gitster@pobox.com>]

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

> 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).