3.3.7 git tag was moved?

[danielbprice]

Issue Description

Until today, we have been using v3.3.7; previously this tag was applied to commit ID 2e9f4ea. However the tag seems to have been moved to a different commit, ba1891b. This breaks dep, at least. And it seems like a really scary practice. Why was this done?

If you browse to

echo/echo.go

Line 222 in ba1891b

Version = "3.3.dev"

, you will see that the version is now listed as 3.3.dev instead of 3.3.7.

Version/commit

v3.3.7

[dhduvall]

I see that the same problem exists with the v3.3.5, v3.3.6, and v3.3.8 tags: they all have the wrong Version, and they all seem to have been moved from their previous commits. I don't have data on newer tags.

[dmlittle]

I think history might have been rewritten on the master branch? If this is the case I think the reason we can still see the original commits on GitHub is because there are forks that still have those commits and GitHub shares the git objects between forks.

Fetching the repository locally and trying to access commit 2e9f4ea shows it doesn't exist.

$ git checkout 2e9f4ea4e010fa328318107ba074b1b72381c571
fatal: reference is not a tree: 2e9f4ea4e010fa328318107ba074b1b72381c571
$ git show 2e9f4ea4e010fa328318107ba074b1b72381c571
fatal: bad object 2e9f4ea4e010fa328318107ba074b1b72381c571

I agree with @danielbprice that this is a really scary practice and should never be done. Specially given that Go uses git repositories such as GitHub as its source for packages. Rewriting history on the master branch can break everyones integration.

[alexaandru]

I'm sorry, this was me, I did reapply those tags on the master branch as they were all applied on forks, in an attempt to get go modules working :-( It didn't work in the end anyway, and we released a v4 properly instead. Tags v3.3.9 and v3.3.10 were applied on master from the start and never tampered with.

Apologies for this attempt of a fix, and rest assure that it was the first and the last time we used something like that on the project. You can see the whole discussion about it in #1253 and #1244

Hopefully you can upgrade to the latest v3 release (or even better, to v4 if you meet the required Go version, listed on the README).

If there's anything I can do to help (besides never doing this again), please let me know.

[alexaandru]

Also, FWIW I reapplied those tags right at the point where the forks were, so they effectively point to the same functionality as before minus the version change (from 3.3.dev to the respective tag) which happened on the forks, not on the master branch. But as I mentioned, if you can use a latter version instead, those tags are nice and clean (and the version too).

[dhduvall]

@alexaandru, can you move the tags back to where they were and push the result? If you no longer have the commit objects somewhere, I'm sure the community can help collect them.

The fallout from this may be wider than is practical for all dependent projects to fix it up on their end, even if an upgrade is doable. This also breaks builds of old versions, which may not be something that can be fixed up.

[alexaandru]

@dhduvall looking into it, but then again it will break for people who pulled it since they were changed..

[dhduvall]

Fair enough; though a) this change was in error, and b) people and projects depending on it will only have been doing so for a few weeks, rather than up to almost a year.

There's no perfect answer here. ☹️

[alexaandru]

Found them all, thanks to git fsck --unreachable. Can anyone confirm this is correct?

1. v3.3.5 ce4a31 -> 6d227d
2. v3.3.6 c185eb -> 1abaa3
3. v3.3.7 ba1891 -> 2e9f4e
4. v3.3.8 c54d9e -> c7eb8d

@dhduvall @dmlittle @danielbprice @vishr @im-kulikov

[alexaandru]

Going to push them. Indeed, these tags were depended on for almost a year, the new tags only for 3-5 days, so the people affected by the retagging are a lot more than the ones that could be affected by restoring the tagging. If anyone already updated to a latter version (v3.3.9+) they should be unaffected. Actually, if anyone pulled in the last few days they should have pulled one of the newer tags anyway.

Revert it is, before this spreads too wide...

[alexaandru]

The tags are now restored: @dhduvall @dmlittle @danielbprice @vishr @im-kulikov

Could you please confirm it's working OK on your ends? Thank you and once again sorry for this :(

[alexaandru]

v4 still builds OK

[alexaandru]

Problem was resolved for 42wim/matterbridge#698 so likely it should be resolved to everyone else affected by this. Will keep this story open for a few more days so that people coming in for this issue can find it easy, and then if no one else has other reports infirming the fix worked, I'll close it.

[dhduvall]

Our build dependent on v3.3.7 is working again, and the hashes for the versions are the ones present in my old copy. Thanks for the quick turnaround!

[alexaandru]

The least I could do after the mess I caused :(

Thank you for the confirmation! Have a great day! :)