Thread (2 messages) flat view 2 messages, 1 author, 2016-06-15

Re: Tag peeling peculiarities

From: Michael Haggerty <hidden>
Date: 2016-06-15 22:56:23

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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help