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$(echo .)mit.edu \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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