Jeff King <peff@xxxxxxxx> writes:
> There's this gem in ref-filter.c, which blames back to your 9f613ddd21
> (Add git-for-each-ref: helper for language bindings, 2006-09-15):
>
> /*
> * NEEDSWORK: This derefs tag only once, which
> * is good to deal with chains of trust, but
> * is not consistent with what deref_tag() does
> * which peels the onion to the core.
> */
> return get_object(ref, 1, &obj, &oi_deref, err);
>
> Which isn't to say it isn't useful to be able to do a single-layer peel,
> but I can't think of another part of the system which does so (unless
> you've asked to peel to a specific type, of course).
Quite honestly, I think the "only once" behaviour outlived its
usefulness, without other "features" that may help make it more
useful. To help a script that wants to do "chains of trust", it may
first appear to be useful to peel only one layer, revealing that the
tagged object is another tag, and that was the thinking behind the
NEEDSWORK comment.
But after we learn that a ref "refs/tags/foo" points at a tag object
that points at another tag object, what can the script do? It
cannot feed the other tag found that way back into --format=%(*<thing>)
machinery of for-each-ref, as the command and its variants, the "--list"
mode of "branch" and "tag" commands, only work on the object at the
tip of refs. The script must manually peel the tag one layer at a time.
And that "manually" has to be really manual. No ^{<type>} suffix
allows scripts to peel just one layer, so inside a loop, the script
has to say "cat-file tag <object>" and parse the "object" header
from the output.
The only thing that gets affected if we changed %(*<thing>) to fully
peel tags is a tag that points at another tag, and the traditional
behaviour to peel only one layer, while it _might_ have been done as
a good first step to add more support for chain of trust, is not all
that useful for such a tag, I am not sure if the current behaviour
is defensible.
