LarsH
LarsH

Reputation: 28004

Why does an annotated tag object store the tag name?

As seen in this answer, a git annotated tag has several properties, e.g.

> git cat-file -p v0.1

object 5cf4de319291579d4416da8e0eba8a2973f8b0cf
type commit
tag v0.1
tagger JDB <[email protected]> 1521058797 -0400

Version 0.1-beat

The first two properties give the SHA1 and type of the target object that the tag is pointing to. The third property gives the tag's name, v0.1.

But this tag is represented as a file .git/refs/tags/v1.0. So we already have a way to map from the string v0.1 to the tag object and its properties. Why would we need the tag object to also include the tag name in its properties? Branches don't store their names. Commits objects don't store their SHA1's. Is there some situation where you'd have a reference to a tag but not to its name?

Upvotes: 2

Views: 174

Answers (2)

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

Apart from your own answer (tag pointing to tag by object ID), other reasons you might want the tag object to store the tag name:

  • If the ref is "loose", then as you say it is stored as .git/refs/tags/v0.1. But it might be packed instead. So if you want to rely on the refs metadata to map the tag name, it's not that easy. (And anyway, mucking around in the .git directory by hand should always be Plan B at best.)

  • The object hash, and in the case of signed tags the signature, would not cover the tag's filename. If you want an assurance that commit 5cf4de319 is what's meant by "v0.1", then you need the tag object to explicitly store that fact.

UPDATE

I'm again not sure if this translates into a "practically important" reason, but here's one more thing to think about:

What, really, is the difference between an annotated tag vs. a lightweight tag pointing to the tag object from an annotated tag? Best answer I have: name mismatch.

Upvotes: 4

LarsH
LarsH

Reputation: 28004

OK, the answer I referenced in this question also contains a clue to an answer to this question: A tag that points to a tag uses the target tag's SHA1, not its name, as the reference.

So if tag2 is created pointing to tag1, tag2 points to the tag1 object without actually revealing tag1's name. Therefore if any git command or UI has to dereference tag1, it would have no direct way of knowing that the tag it points to is called tag2, if tag2's object didn't contain that information.

Maybe there are other reasons, but that's the one I could think of. Maybe there are other things (besides a tag) that might reference a tag by its SHA1, and therefore need the name of the referenced tag to be supplied by the referenced tag object.

Upvotes: 2

Related Questions