git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	git discussion list <git@vger.kernel.org>
Subject: Re: Tag peeling peculiarities
Date: Wed, 13 Mar 2013 17:58:00 -0400	[thread overview]
Message-ID: <20130313215800.GA23838@sigill.intra.peff.net> (raw)
In-Reply-To: <7vwqtb2ood.fsf@alter.siamese.dyndns.org>

On Wed, Mar 13, 2013 at 10:29:54AM -0700, Junio C Hamano wrote:

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > It is not
> > clear to me whether the prohibition of tags outside of refs/tags should
> > be made more airtight or whether the peeling of tags outside of
> > refs/tags should be fixed.
> 
> Retroactively forbidding presense/creation of tags outside the
> designated refs/tags hierarchy will not fly.  I think we should peel
> them when we are reading from "# pack-refs with: peeled" version.
> 
> Theoretically, we could introduce "# pack-refs with: fully-peeled"
> that records peeled versions for _all_ annotated tags even in
> unusual places, but that would be introducing problems to existing
> versions of the software to cater to use cases that is not blessed
> officially, so I doubt it has much value.

I agree. The REF_KNOWS_PEELED thing is an optimization, so it's OK to
simply omit the optimization in the corner case, since we don't expect
it to happen often. So what happens now is a bug, but it is a bug in the
reader that mis-applies the optimization, and we can just fix the
reader.

I do not think there is any point in peeling while we are reading the
pack-refs file; it is no more expensive to do so later, and in most
cases we will not even bother peeling. We should simply omit the
REF_KNOWS_PEELED bit so that later calls to peel_ref do not follow the
optimization code path. Something like this:

diff --git a/refs.c b/refs.c
index 175b9fc..ee498c8 100644
--- a/refs.c
+++ b/refs.c
@@ -824,7 +824,10 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
 
 		refname = parse_ref_line(refline, sha1);
 		if (refname) {
-			last = create_ref_entry(refname, sha1, flag, 1);
+			int this_flag = flag;
+			if (prefixcmp(refname, "refs/tags/"))
+				this_flag &= ~REF_KNOWS_PEELED;
+			last = create_ref_entry(refname, sha1, this_flag, 1);
 			add_ref(dir, last);
 			continue;
 		}

I think with this patch, though, that upload-pack would end up having to
read the object type of everything under refs/heads to decide whether it
needs to be peeled (and in most cases, it does not, making the initial
ref advertisement potentially much more expensive). How do we want to
handle that? Should we teach upload-pack not to bother advertising peels
outside of refs/tags? That would break people who expect tag
auto-following to work for refs outside of refs/tags, but I am not sure
that is a sane thing to expect.

-Peff

  reply	other threads:[~2013-03-13 21:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-13 14:59 Tag peeling peculiarities Michael Haggerty
2013-03-13 15:34 ` Michael Haggerty
2013-03-13 17:29 ` Junio C Hamano
2013-03-13 21:58   ` Jeff King [this message]
2013-03-14  4:41     ` Michael Haggerty
2013-03-14  5:24       ` Jeff King
2013-03-14  5:32         ` Jeff King
2013-03-14 15:14           ` Junio C Hamano
2013-03-14 11:28         ` Michael Haggerty
2013-03-14 13:40           ` Jeff King
2013-03-15  5:12             ` Michael Haggerty
2013-03-15 16:28               ` Junio C Hamano
2013-03-16  8:48             ` Michael Haggerty
2013-03-16  9:34               ` Jeff King
2013-03-16 13:38                 ` Michael Haggerty
2013-03-18  3:17                   ` Michael Haggerty
2013-03-22 17:42                   ` 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=20130313215800.GA23838@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    /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).