profile
viewpoint

Ask questionscmd/go: 'go get repo@<commit>' succeeds when <commit> is the full hash of an unpublished commit

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

<pre> $ go version go version go1.11.4 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

Yes, I also tried go1.12

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GOARCH="amd64" GOBIN="" GOCACHE="/var/folders/_b/d1934m9s587_8t_6ngv3hnc00000gp/T/tmp.TJtxkDDu/gp/gocache" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/var/folders/_b/d1934m9s587_8t_6ngv3hnc00000gp/T/tmp.TJtxkDDu/gp" GOPROXY="" GORACE="" GOROOT="/Users/ikorolev/.gvm/gos/go1.11.4" GOTMPDIR="" GOTOOLDIR="/Users/ikorolev/.gvm/gos/go1.11.4/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/var/folders/_b/d1934m9s587_8t_6ngv3hnc00000gp/T/tmp.TJtxkDDu/go.mod" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_b/d1934m9s587_8t_6ngv3hnc00000gp/T/go-build355884507=/tmp/go-build -gno-record-gcc-switches -fno-common" </pre></details>

What did you do?

go get fails to resolve just a single revision from our repository, unless full commit string is passed

cd `mktemp -d`
go mod init example.com/test
mkdir gp
export GOPATH=$PWD/gp
go get <repo>@51190595363f3b59b43fd589f4cfde1045d5b657
cat go.mod

I get

module example.com/test

require <repo> v0.0.0-20190214201838-51190595363f // indirect

Then I clean my mod cache go clean -modcache, try to get the required revision and receive an error:

$ go get <repo>@v0.0.0-20190214201838-51190595363f
go: finding <repo> v0.0.0-20190214201838-51190595363f
go: <repo>@v0.0.0-20190214201838-51190595363f: unknown revision 51190595363f
go: error loading module requirements

go get <repo>@51190595363f also fails. Though it works on some other commit go get <repo>@413960593a24cfdc

I really don't know how to reproduce it in public to debug this and have no ideas where it comes from.

Would be glad to provide any info if you give me some hint.

What did you expect to see?

go get must succeed.

What did you see instead?

go: <repo>@v0.0.0-20190214201838-51190595363f: unknown revision 51190595363f
go: error loading module requirements
golang/go

Answer questions mwf

Is the commit in question reachable from any published branch or tag?

Yes, this makes sense, it became unreachable at some moment. Gitlab was able to find it, that's why I didn't check it :(

The interesting thing is - git can't find the commit after git clone and checkout: fatal: reference is not a tree: 51190595363f3b59b43fd589f4cfde1045d5b657

So I can't imagine how go was able to find the reference in the repo :)

I can't name it a bug for sure, but I believe everyone will win if the behaviour becomes more stable. If go resolves the full commit and you think it's OK, then it must be able to resolve the partial ones.

But I believe it's much better to forbid resolving such commits. The best option is to return some descriptive error like the commit exists, but not found in repository tree instead of go: <repo>@v0.0.0-20190214201838-51190595363f: unknown revision 51190595363f. But that would also require partial hash resolving, which seems to be missing now.

useful!

Related questions

cmd/link: segmentation fault during mach-o linking hot 3
x/xerrors: fails to compile on tip hot 1
vendor/golang.org/x/xerrors/adaptor_go1_13.go:16:14: undefined: errors.Frame ... hot 1
cmd/go: `go clean <package>` downloads modules hot 1
cmd/cgo error: runtime: unknown pc 0x7fff5c805b86 hot 1
runtime: crash with "invalid pc-encoded table" hot 1
cmd/vet: potential false positive in the "suspect or" check hot 1
cmd/link: showing many ld warnings of "building for macOS, but linking in object file" hot 1
cmd/go: major version without preceding tag must be v0, not v1 - breaks build of github.com/go-check hot 1
runtime: macOS Sierra builders spinning hot 1
cmd/go: Problem using go modules hot 1
cmd/go: "unrecognized import path" for local packages after updating to go1.13 hot 1
cmd/go: "found, but does not contain package" error refers to replaced version instead of its replacement hot 1
x/tools/gopls: format feature doesn't follow `goimports` hot 1
cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src hot 1
Github User Rank List