I'm having some weird behavior with git right now.
I have a codebase that has a commit tagged v2.3.0
If I run git log, I can see that my latest commit hash is:
commit b2ee576083607b7ba451b72642a77ca3309e4ac9 (HEAD, tag: v2.3.0, origin/staging, origin/master, origin/develop, origin/HEAD, master)
Author: B <b@b.com>
Date: Thu Apr 1 16:53:48 2021 +0000
Cool! This lines up with what I see in my git repo as well
If I run git checkout v2.3.0, I also get to the same commit hash. Sweet.
However, if I run git rev-parse v2.3.0, to see which commit hash lines up with my tag, I get the commit hash 85607530aa64da4df34e7160d073df5c2699439b...???
If I then try to check out that commit hash, my codebase will still say it's at b2ee576083607b7ba451b72642a77ca3309e4ac9 (i.e. it didn't change)
So as far as I can tell, I have this weird phantom commit hash that is nowhere to be found in my git repo but that seems to point to my actual commit hash. This is causing me problems because I have a script that relies upon correct output from git rev-parse.
I have git version git version 2.25.1
Anyone have any idea what's goin on here?
That's not a commit hash. That's the hash ID of the annotated tag, v2.3.0. Annotated tags are objects in their own right, so they have their own hash IDs. Like names (branch and tag names for instance), they in turn point to some other object—usually directly to a commit.
To have git rev-parse turn any tag into the final object to which it might point, use the ^{} suffix, which means if this is a tag object, follow it to its destination, and if that's another tag, keep following. If the name you supply could point to something other than a commit object—e.g., to a tree or blob object—and you want to be sure that it does in fact point to a commit, use the ^{commit} suffix:
git rev-parse v2.3.0^{commit}
If the tag points to anything other than a commit, this will produce an error (nonzero exit status), so check for that.