@bcmills @matloob

go get does a lot less work and loads many fewer packages than go mod tidy does.
Making go get tidy go.sum (and go.mod) would make it more expensive.
It's unclear that's worthwhile. If you need go mod tidy, it's easy to run.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

go get does a lot less work and loads many fewer packages than go mod tidy does.
Making go get tidy go.sum (and go.mod) would make it more expensive.
It's unclear that's worthwhile. If you need go mod tidy, it's easy to run.

go get does a lot of work when fetching resources from the network and is often quite slow for me. I would expect go mod tidy to be much quicker when the entire structure already exists locally.
I'm wondering if there's perhaps a subset of go get operations (like for simple updates as described above where a single main dependency is upgraded without side effects) that could be included?

Happy to have this closed if not feasible, thank you.

I think there are some cases where go get could maintain more cleanliness than it does today, although I agree that it isn't feasible to make it as precise as go mod tidy.

The cases where it would be straightforward to add precision are:

1. If some version of a module was present in the module graph at the start of go get, and that version is no longer present in the module graph after go get, then we could reasonably discard the go.mod checksum for that version. (We know that it used to be needed to compute the module graph and no longer is.)
2. If some version of a module was selected in the module graph at the start of go get, and that version is no longer selected after go get, then we could discard the zipfile checksum for that version (and perhaps download the newly-selected version and add its checksum).

That said, those increases in precision still wouldn't guarantee that go get preserves tidiness every time. (For example, the import graph can change arbitrarily in packages that are not relevant to the specific package requested on the command line, which can cause previously-irrelevant checksums to become relevant or vice-versa.)

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

I‘m a bit confused with the summary. In terms of „always“ tidy it seems that it‘s a decline. In terms of „more often tidy than today“ it seems to be „accept“. Just to clarify- the latter would imho be better than nothing. If not worth complexity vs benefit a brief comment would be appreciated.

No change in consensus, so declined.
— rsc for the proposal review group