cmd/go: "go get -u" should handle missing hash

[shuLhan]

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

$ go version
go version devel +6dc88be30d Mon May 13 17:25:28 2019 +0700 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/ms/go/bin"
GOCACHE="/home/ms/.cache/go-build"
GOENV="/home/ms/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ms/go"
GOPROXY="https://proxy.golang.org"
GOROOT="/home/ms/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/ms/share/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build143933761=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Create a module with the following go.mod file,

module github.com/shuLhan/sandbox/issuenew

go 1.13

require golang.org/x/xerrors v0.0.0-20190513163551-000000000001

The VCS hash for package xerrors is deliberately modified to point to commit hash that does not exist (000000000001).

On the package module root directory, run go get -u golang.org/x/xerrors.

What did you expect to see?

The "go get -u" command should update the package to latest commit on repository even if hash is not found as long as package use "latest" (incompatible?) mode.

In a perfect world, we will never seen a commit missing from master branch. However, sometimes rebase and force push happened, for any reason.

Rationale: when user use "latest" mode, we assume that they know what they are doing and the know what would happened.

What did you see instead?

The "go get -u" command return 410 Gone.

go: finding golang.org/x/xerrors v0.0.0-20190513163551-000000000001
go: golang.org/x/[email protected]: reading https://proxy.golang.org/golang.org/x/xerrors/@v/v0.0.0-20190513163551-000000000001.info: 410 Gone

Currently, the only way to fix this is by re-initializing module back (removing "require" statements and removing go.sum file).

[andybons]

@bcmills @jayconrod

[bcmills]

This is somewhat related to #30831 and #26902, in that we're emitting an error before the upgrade due to a failure that wouldn't be present after upgrading anyway.

[rsc]

we're emitting an error before the upgrade due to a failure that wouldn't be present after upgrading anyway.

We don't know that. go get -u might choose a "latest" that is before that pseudo-version, or maybe that module contains within it other requirements that are newer than "latest" for their own modules. In general ignoring unreachable modules is not safe.

[bcmills]

@rsc, since the existing entry in the go.mod file is a well-formed semantic version, we can compare it with latest and only report an error if it is semantically lower.

That said, if we can't fetch the listed commit, then we also don't know what packages it imports or what other module versions it requires. If we don't have that information, then we could indeed end up downgrading one or more transitive dependencies.

For rebases and force-pushes in particular, in many cases you will be able fetch the missing version from a proxy or mirror, and for the remainder you can always hand-edit (or go mod edit) the go.mod file.

[thepudds]

@bcmills was this intentionally closed? Just checking.

[bcmills]

Yes, this was closed intentionally: if we can't load the module graph, we can't (in general) decide which modules to upgrade.