Git commit overwritten causes builds to fail

[dan-hipschman]

Hello,

Thanks for reflections!

We're using this project and had it pinned in Gopkg.lock as follows:

[[projects]]
  digest = "1:c17f50b4ccbba568a6fc10b06a24bb8ac99077470fd48a905759f9914d631dd7"
  name = "github.com/oleiade/reflections"
  packages = ["."]
  pruneopts = "NUT"
  revision = "2b6ec3da648e3e834dc41bad8d9ed7f2dc6a9496"
  version = "v1.0.0"

Earlier today it looks like our builds started failing because the commit 2b6ec3da648e3e834dc41bad8d9ed7f2dc6a9496 no longer exists in this repo. I don't have the full history, but it looks like new commits were force pushed over old commits and and the v1.0.0 tag was updated.

Just a heads up that this will break our builds (and whoever else is using it this way). We can update the lock file on our side, but just letting you know it would be appreciated if new commits are only merged and never rebased so history is preserved, and tags aren't updated.

Thanks again! :)

[filipeandre]

Please don't override tags.

[sashayakovtseva]

same issue with go modules :((

[huucp]

same issue with go modules :((

I try to remove my go.sum, use go clean -modcache, then go mod tidy again.
Sometimes it's work, sometimes it's not.
Now, I have to hardcode the hash in go.sum to make the CI build run, but I cannot run the app in local.

[sashayakovtseva]

@huucp this works without need to hardcode hashsum:

1. go clean --modcache
2. rm go.sum
3. GOSUMDB=off go mod tidy or whatever mod command you need

once done, no need for GOSUMDB=off any more

[anhthien-bic]

@huucp
export GOSUMDB=off && go clean -modcache && rm go.sum && go mod tidy

[lagren]

That solution is sadly not possible when using external systems, e.g. GitHub's Dependabot:

verifying github.com/oleiade/reflections@v1.0.0/go.mod: checksum mismatch
	downloaded: h1:rdFxbxq4QXVZWj0F+e9jqjDkc7dbp97vkRixKo2JR60=
	go.sum:     h1:RbATFBbKYkVdqmSFtx13Bb/tVhR0lgOBXunWTZKeL4w=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

Maybe releasing a 1.0.1 could work?

[oleiade]

Hi folks,

Really sorry about that!! Thanks for reporting it @dan-hipschman-od (and your kindness about it) much appreciated. I updated all my libraries to support go modules in one go and wanted to "mark the hit" (like we say in french). I realize now, in hindsight, that rewriting the master history, and overriding the existing release was a terrible idea. That's a learning for me 👍

I will release a v1.0.1 right away to address the issue that have been mentioned above.
Thanks for your patience 🦕

[oleiade]

I have pushed a v1.0.1 tag, and published a release. Let me know if you're still experiencing issues after bumping the version you use on your side. Thanks for your support 🙏