From: Michael Haggerty <mhagger@alum.mit.edu>
To: git discussion list <git@vger.kernel.org>
Cc: Junio C Hamano <gitster@pobox.com>
Subject: Re: Tag peeling peculiarities
Date: Wed, 13 Mar 2013 16:34:25 +0100 [thread overview]
Message-ID: <51409C81.2010200@alum.mit.edu> (raw)
In-Reply-To: <51409439.5090001@alum.mit.edu>
On 03/13/2013 03:59 PM, Michael Haggerty wrote:
> I have been working on the pack-refs code [1] and noticed what looks
> like a problem with the handling of peeled refs in the packed-refs file
> and in the reference cache. In particular, the peeled versions of tags
> outside of refs/tags are *not* stored in packed-refs, but after the
> packed-refs file is read it is assumed that such tags cannot be peeled.
>
> It is clear that annotated tags want to live under refs/tags, but there
> are some ways to create them in other places (see below). 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.
>
> Example:
> [...]
I should have mentioned that I already understand the programmatic
*cause* of the behavior that I described in my last email:
* in pack-refs.c:handle_one_ref(), tags that are not in refs/tags are
explicitly excluded from being peeled.
* in refs.c:read_packed_refs(), if the packed-refs file starts with
"# pack-refs with: peeled "
then the REF_KNOWS_PEELED bit is set on *every* reference read from
the file into the packed refs cache, whether or not it is under
refs/tags.
* in refs.c:peel_ref(), if a refs cache entry has its REF_KNOWS_PEELED
bit set but its peeled field is empty, then it is assumed that the
reference is unpeelable.
What I am *not* clear about is which of these steps is incorrect, and
also whether this problem will have any significant ill effects.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2013-03-13 15:34 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 [this message]
2013-03-13 17:29 ` Junio C Hamano
2013-03-13 21:58 ` Jeff King
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=51409C81.2010200@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.