CODEWITHSUNDEEP
git
bsky
bsky

Reputation: 20242

Git tag pointing to commit that doesn't appear in the logs

I ran a script which was supposed to create a git tag.

When I search for that tag: git show-ref --tags

I get a commit: 020795b07753c02034500f10f17dbc82edf refs/tags/my-tag

Then, when I search for the branch containing that commit:

git branch --contains 020795b07753c02034500f10f17dbc82edf

I get a branch: feature/my-feature

The problem is that if I search 020795b07753c02034500f10f17dbc82edf through the logs of feature/my-feature (obtained with git log), I can't find it.

Any idea why the tag is pointing to a commit that isn't in the logs?

Upvotes: 1

Views: 550

Answers (1)

torek
torek

Reputation: 489648

As Lasse V. Karlsen said in the comments, what you have is an annotated tag.

The part that does not make sense is your comment-answer to what happens if you run git cat-file -p 020795b07753c02034500f10f17dbc82edf. You said you got:

object 020795b07753c02034500f10f17dbc82edf
type commit
tag my-tag [maven-release-plugin]
copy for tag my-tag

This would imply that you have found another hash collision: a tag object whose ID is 020795b07753c02034500f10f17dbc82edf, yet which one which points to a commit object whose ID is also 020795b07753c02034500f10f17dbc82edf. This is literally impossible—not that a collision is impossible (see https://shattered.it/), but rather that Git has stored two different objects under a single ID. This is because Git's "true name" for an object, the way it finds the object's contents, is the hash ID. Once Git has stored one object with one ID, it refuses to store another, different object with the same ID. If 020795b07753c02034500f10f17dbc82edf is already a commit, an attempt to drop a tag in under the name 020795b07753c02034500f10f17dbc82edf is simply rejected.

Here is an example of an annotated tag in the Git repository for Git itself:

$ git show-ref --tags
[massive amount of output snipped]
f883596e997fe5bcbc5e89bee01b869721326109 refs/tags/v2.9.3

Here v2.9.3 is a tag name—a reference in the refs/tags/ namespace—pointing to Git object f883596e997fe5bcbc5e89bee01b869721326109. The object itself is an annotated tag:

$ git cat-file -t f883596e997fe5bcbc5e89bee01b869721326109
tag

and its contents are the tag object, which points to the commit object:

$ git cat-file -p f883596e997fe5bcbc5e89bee01b869721326109
object e0c1ceafc5bece92d35773a75fff59497e1d9bd5
type commit
tag v2.9.3
tagger Junio C Hamano <[email protected]> 1471018679 -0700

Git 2.9.3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXrfa3AAoJELC16IaWr+bLLY8QANE8ZaL+qyhjC8fHfJhhr4cY
GeZe8x9SSTNv0WzOvXGf34XwdpOYYiVrUrwlgBx6HglhDeYzCp4kObR5sHwtTKgN
r0KKvAuvjlZJm5tWNavu2fDoHKhE+QRP3AagaF5iDX68QLjhGOS8+zAWqNRukh7y
X6tmdUhGhWPtUKr1LBUVd94GdF8v5tggCNDcqZZj+dPIosPvlDqGWT29/IKyCU/a
4o91hD5jWkMybfyTwzZDsSYmtB4TXxML8idJUdZQ5LyyPq9uSU63lgP8ljwivYzy
oiVB1OOawym7+PeyvZEvLvpFW1Ks7YSTCMNQjn4Y3dxYF3szuoPZV3ztCzngoEIG
qSuzA0sn6zfaMWAQF2Yjix2zBfSlBXmxNzA/WqYAyNr3Lsias5A/X9nFtowSEi56
0iFVilSsKWc3bC0oNEyYFlUs1kY4rR2S5kbBXTJ6l75bvDvXP/L+JXm4QcRCr92i
6i7NYxeNqfnZZV72KeG2EqZaL4mrXAY68Mjv8jd/80oogCUDBhlTKd8IK/WG64M9
VjfHpvKmtkBaIq6Zz0cQxO1pe4F64GzSNzlC9l787iQCnUW+4BO7OyEAByJWzHn+
D5oSfWI79MDVdvw2UlHvk1tg4bNNYLcNwTGZGQhcwXudv7hpzW3s1PBNY0LzXGux
LBOdlVeCcsYGr2rsRMbm
=PhTI
-----END PGP SIGNATURE-----

(this particular tag has a GPG signature). The actual commit is e0c1ceafc5bece92d35773a75fff59497e1d9bd5. It is this (different) commit object that is contained in various branches. The tag object is in no branches. Aside from its hash ID, the way you—or Git—find the tag object is by looking up the tag name, refs/tags/v2.9.3. One then finds the commit by reading the tag object.

Since this tag object refers to additional Git object e0c1ceafc5bece92d35773a75fff59497e1d9bd5, that is the target (my term) of this annotated tag. The tag object claims that the target has type commit, so git cat-file -t should say it is a commit, and it does:

$ git cat-file -t e0c1ceafc5bece92d35773a75fff59497e1d9bd5
commit

and the commit object in turn looks normal:

$ git cat-file -p e0c1ceafc5bece92d35773a75fff59497e1d9bd5
tree 3cc4bf42e1b9aaa3c650af7247019890f7e01c95
parent 9b601eafd1437df2e11b032bfbfd1ac5d32d3290
author Junio C Hamano <[email protected]> 1471018671 -0700
committer Junio C Hamano <[email protected]> 1471018671 -0700

Git 2.9.3

Signed-off-by: Junio C Hamano <[email protected]>

and all is well in Git-land.

Upvotes: 1

Related Questions