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
[email protected]
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
