-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag and commit for v1.12.2 does not belong to any branch #1083
Comments
As per #1079 (comment) agree - sorry for the confusion. |
Not yet fixed, I'm working on a PR. |
Thanks! We will create some docs to ensure the right process for this in future. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 therelease-1.12
branch.In the end, I fetched that commit directly into a pseudo remote branch:
I could then merge that branch into the
sparsehistogram
branch, so that Go Modules works again with thesparsehistogram
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
?The text was updated successfully, but these errors were encountered: