On Thu, Mar 21, 2019 at 12:04:22PM -0700, Bryan Turner wrote:
> > Why does it show two entries? In my `packed-refs` file, it also shows
> > a strange revision for the tag (I expect to see just 1 SHA1). Not sure
> > if it is related:
> >
> > ```
> > 66c41d67da887025c4e22e9891f5cd261f82eb31 refs/tags/4.2.0.1900
> > ^2fcfd00ef84572fb88852be55315914f37e91e11
> > ```
>
> This part, though, is normal for "packed-refs". The first line shows
> the annotated tag object's hash ("66c41d67da8") and the tagged
> object's hash ("2fcfd00ef8"). You can see that "2fcfd00ef8" matches
> the tagged commit output by "git show". The leading "^" on the second
> line is how Git knows the line identifies a peeled tag's target rather
> than the start of a new ref. If your "packed-refs" starts with
> "peeled" (and maybe "fully-peeled") then every annotated (or signed)
> tag in the file should have a second line prefixed by "^".
Nicely explained.
I think there's one other interesting bit of trivia, since we seem to be
dealing with a tag-of-a-tag here. We store only a single peeled value
for each ref, whatever is at the bottom (which is always a non-tag). So
in this case of a tag that points to a tag that points to a commit, the
peeled value is the commit, and the tag in the middle isn't mentioned.
Likewise for upload-pack output, which mentions the peeled objects (so
that clients can auto-fetch tags). It only gives the full peeling.
In theory we could store and advertise the intermediate objects, but I
don't think anybody has ever cared enough about this case to explore
that (and this is mostly an optimization; it should all work correctly,
and I recall fixing some bugs over the years).
-Peff
