Skip to content

cmd/go: 'go get repo@<commit>' succeeds when <commit> is the full hash of an unpublished commit #30434

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mwf opened this issue Feb 27, 2019 · 7 comments
Closed

cmd/go: 'go get repo@<commit>' succeeds when <commit> is the full hash of an unpublished commit #30434

mwf opened this issue Feb 27, 2019 · 7 comments
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.13

Comments

@mwf
Copy link

mwf commented Feb 27, 2019

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

$ go version
go version go1.11.4 darwin/amd64

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)?

go env Output
$ 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"

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
@mwf
Copy link
Author

mwf commented Feb 27, 2019

@gopherbot please add label modules

@bcmills
Copy link
Contributor

bcmills commented Feb 27, 2019

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

If not, then that would explain this behavior, and it's arguably a bug that we allow the version to be resolved at all.

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 27, 2019
@bcmills bcmills added this to the Go1.13 milestone Feb 27, 2019
@mwf
Copy link
Author

mwf commented Feb 27, 2019

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.

@bcmills
Copy link
Contributor

bcmills commented Feb 27, 2019

unknown revision seems fine, given that the revision really can't be found starting from the published refs, but go get <repo>@51190595363f3b59b43fd589f4cfde1045d5b657 should return the same error.

@bcmills bcmills changed the title cmd/go: go get repo@commit fails on partial commit hash cmd/go: 'go get repo@<commit>' succeeds when <commit> is the full hash of an unpublished commit Feb 27, 2019
@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Feb 27, 2019
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 27, 2019
@bcmills
Copy link
Contributor

bcmills commented Feb 27, 2019

CC @jayconrod

@jayconrod jayconrod self-assigned this Feb 27, 2019
@FiloSottile FiloSottile mentioned this issue Apr 1, 2019
Closed
@FiloSottile
Copy link
Contributor

Closing this in favor of #31191.

I am also confused by something: once 51190595363f3b59b43fd589f4cfde1045d5b657 became unreachable, were you still able to go get it with a full commit string and a clean modcache?

That would conflict with my understanding that git does not allow unreachable refs to be fetched remotely. (If it were already in the modcache it's reasonable that the go tool would find it there.)

@bcmills
Copy link
Contributor

bcmills commented Apr 1, 2019

I am also confused by something: once 51190595363f3b59b43fd589f4cfde1045d5b657 became unreachable, were you still able to go get it with a full commit string and a clean modcache?

I believe so, yes. The stock Git server does not serve unreachable refs, but the underlying protocol does not preclude it, and some alternate implementations (such as GitHub) are more lax.

@golang golang locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
5 participants
@jayconrod @FiloSottile @mwf @bcmills @gopherbot