Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: downgrading a module with `go get` retains indirect dependencies #26481
What version of Go are you using (
In the typical case you can just check out the previous
It gets to be more of a problem when you're upgrading and downgrading a bunch of unrelated dependencies in the same change, but that seems easy to avoid: how big is this problem in practice?
VCS checkout is great, but it helps only in trivial case when you update, run tests and determine the failure. Then you rollback with VCS and you're done.
But imagine more complex situation, when the bug is hidden - either it's not covered with tests properly or it's just too complex and happens in some particular circumstances in runtime. With a panic for example or even some slow goroutine or file descriptor leak.
So the gap between updating the go.mod and getting the bug could be hours-days. And even several application releases could happen in this time, with other dependency upgrades possible.
Imagine this bug is in production and all you want in this minute is a quick hotfix. You may try to use the VCS, checkout the dependency version from that commit and just take it.
So in case of VCS checkout you will have to doublecheck the transitive dependencies in go.mod after
And the current behaviour doesn't match with doc from
It doesn't downgrade the other dependencies now actually.
PS There is a typo in the docs :) dependenceis -> dependencies
Rolling back to a previous state is conceptually very different from
This is working as designed, as intended, and as documented: go get means make the exact, unique minimum number changes to effect that command, nothing more, nothing less. You are asking for go get to magically infer the "more" you want. That's just not possible.
You are asking for version control on go.mod. The go.mod file has been engineered to be version control-friendly, precisely so that job can be reasonably done with your version control system of choice, instead of having the go command reimplement a new version control system of its own.
Sorry, I know this is not the answer you want.