Modify `go get -u` semantics for modules

[aanthony1243]

What version of Go are you using (go version)?

1.11

What operating system and processor architecture are you using (go env)?

darwin/amd64

When running go get -u <module>, it seems that the semantic should be "update this one module". However, as it is currently documented, it will not only update that module, but also fetch the latest updates from all dependent modules.

To update just a single module, I can run go get <module>, but here I believe the intuitive semantic is "go get this module if you don't already have it."

Proposal: add a -R flag to indicate a recursive module update, so that:

1. go get <module> only downloads the latest module if the module is currently not present.
2. go get -u <module> will fetch the latest version of the module according to the rules in go.mod
3. go get -R <module> will fetch the latest version of the module and also fetch the latest dependencies as well.

[bcmills]

go get -u <pkg> has meant “upgrade <pkg> and its transitive dependencies” since long before modules. We aren't changing that for module mode: the idea is to extend the existing go get commands to work with modules, not to replace them with an entirely different set.

go get <module>@latest already means what you propose for go get -u <module>.
go get -m -u <module> already means what you propose for go get -R <module>.

If you only want to get a module if no version of it is already active, you can express that intent explicitly: go list -m <module> || go get <module>. (In most cases, though, it's simpler to let go build, go test, or go mod tidy fetch missing module dependencies rather than adding them explicitly yourself.)

At the moment there is a bit of ambiguity as to whether “transitive dependencies” should apply to packages or to modules in the absence of the -m flag (#26902), but in most cases that does not significantly change the outcome.

See also #28156 and #27643.

(CC @rsc)