From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Bryan Turner <bturner@atlassian.com>, Git Users <git@vger.kernel.org>
Subject: Re: Fully peel tags via for-each-ref?
Date: Wed, 21 Aug 2019 19:00:36 -0400 [thread overview]
Message-ID: <20190821230035.GA26107@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq8srowfkv.fsf@gitster-ct.c.googlers.com>
On Mon, Aug 19, 2019 at 10:50:24PM -0700, Junio C Hamano wrote:
> Bryan Turner <bturner@atlassian.com> writes:
>
> > Is there any way, with "git for-each-ref", to output the "fully"
> > peeled SHA of a tag's ultimate target, regardless of how many layers
> > must be traversed?
>
> I do not think I wrote it to allow different degree of peeling, not
> because I wanted to explicitly forbid a use case for tags that tag
> another tag, but simply because I didn't think of anybody using it
> and didn't see need to support such tags.
>
> If %(*<stuff>) does not peel fully (I do not recall what I did
> offhand), because all other things in Git (like $X~0, $X^{tree},
> etc.) fully peel the outer object until they get to what they want,
> it may even be OK to declare it a bug and "fix" the notation to
> fully peel tags. I dunno.
Yeah, my first thought on reading Bryan's email was that this is so
inconsistent with the rest of Git as to be considered a bug.
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). I'm thinking
especially of the way upload-pack does its advertisement, with two
interesting implications:
1. We store full peels in the packed-refs file[1], so we can show them
in the advertisement without having to access the object. Doing:
git upload-pack . </dev/null >/dev/null
is much cheaper than:
git for-each-ref \
--format='%(objectname) %(refname)%0a%(*objectname) %(refname)^{}' \
>/dev/null
2. When we switched for_each_alternate_ref to using peeled values, we
stopped advertising peeled values for .push haves entirely. There's
some discussion in a10a17877b (for_each_alternate_ref: replace
transport code with for-each-ref, 2017-02-08), but if we _did_ want
to show them, we'd probably want the fully peeled value to match
the rest of the advertisement.
Given that it's not how the rest of Git works, I'd be surprised for
anybody to be relying on the shallow-peeling behavior of for-each-ref.
But if we did want to retain it, it might be worth adding a separate
syntax for a full peel. "%(**objectname)" or something?
-Peff
[1] Storing peeled values in the packed-refs file is itself a pretty
horrible hack. It's really a property of the object itself, and
we're just piggy-backing on the ref storage to make this cached
metadata easily accessible. It would be more appropriate in an
object metadata storage format similar to the commit-graph file.
And then of course we could store both full or partial peels,
depending on the format.
next prev parent reply other threads:[~2019-08-21 23:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 23:22 Fully peel tags via for-each-ref? Bryan Turner
2019-08-20 5:50 ` Junio C Hamano
2019-08-20 21:39 ` Bryan Turner
2019-08-21 23:00 ` Jeff King [this message]
2019-08-22 3:07 ` Junio C Hamano
2019-08-22 4:24 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190821230035.GA26107@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=bturner@atlassian.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).