Tag and commit for v1.12.2 does not belong to any branch #1083
Description
Sorry for touching the topic again, but I think this is actually a problem:
The v1.12.2 tag points to commit e203144 , but this commit is actually not in any branch in this repo. If you go to the commit in the GH web UI, you get:
The problem is that you will usually not fetch this commit if you clone the repo. When Go Modules fetches the version, it apparently fetches the commit directly without paying attention to branches. I tried to merge v1.12.2 into the sparsehistogram branch so that Go Modules would see it as an upgrade to v1.12.2, not a downgrade (which causes all kind of Go Modules pain when trying to run anything with the new sparse histograms). It took me a while to understand that I still didn't have the right commit in my branch despite merging in the release-1.12 branch.
In the end, I fetched that commit directly into a pseudo remote branch:
$ git fetch origin e203144f43306c1f344fbc548fd02c4b79962e30:refs/remotes/origin/foobar
I could then merge that branch into the sparsehistogram branch, so that Go Modules works again with the sparsehistogram branch. Ironically, a byproduct of this is that now commit e203144 actually belongs to a branch again, but not the release branch (which might be confusing to users in yet another way).
My guess is that v1.12.2 was tagged in a review branch before it got merged into the release branch via squashing (thereby rewriting the commit with a different sha). Then, the review branch got deleted, and the tagged commit was lost without branch.
Not sure how to fix this in the best way. Maybe merge (this time for real) e203144 into branch release-1.12 ?