cmd/go: unknown revision converting vendor, but revision exists

[mitchellh]

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

go version go1.11rc2 darwin/amd64

Does this issue reproduce with the latest release?

Latest go1.11 release - yes
Latest go1.10 - no because no modules

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mitchellh/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mitchellh/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/mitchellh/code/3rdparty/go"
GOTMPDIR=""
GOTOOLDIR="/Users/mitchellh/code/3rdparty/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mitchellh/code/go/src/github.com/hashicorp/consul/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/gh/ts3cxwpd7l9cwb2n5z8j51980000gn/T/go-build206170924=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Checkout 542cace9a from https://github.com/hashicorp/consul

$ git clone https://github.com/hashicorp/consul.git 
$ cd consul/
$ git checkout 542cace9a
$ go mod init
go: creating new go.mod: module github.com/hashicorp/consul
go: copying requirements from vendor/vendor.json
go: converting vendor/vendor.json: stat github.com/hashicorp/go-discover@1b9cec3de1d963ee4354e0151cbcc0a976791be6: unknown revision 1b9cec3de1d963ee4354e0151cbcc0a976791be6

What did you expect to see?

Probably no error.

What did you see instead?

Reference to revision 1b9... but if I go to the repo, that exists:
hashicorp/go-discover@1b9cec3

[ianlancetaylor]

CC @bcmills @rsc

[thepudds]

@mitchellh I wonder if that 1b9... commit hash in go-discover is not associated with a branch or tag. The git-based lookup in the go command was tighten up a bit recently.

For example, in #27043 the problem was that the commit hash of interest referenced an unmerged pull request, which the go command now disallows (though it was previously more liberal).

See for example the comment in #27043 (comment) or https://go-review.googlesource.com/c/go/+/129800.

Perhaps you are encountering something in that neighborhood, or perhaps you are seeing something else entirely.

[oiooj]

I think @thepudds is right. The commit hash hashicorp/go-discover@1b9cec3 is not associated with a branch or tag.

[bcmills]

Yep, it's on an unmerged fork in github.com/MagnumOpus21/go-discover.

This seems to be working as intended: we want individual maintainers to be in charge of which commits they publish. (Rejected pull requests and forks by other users should not be available for version resolution.)

[bcmills]

Hmm, and @banks even specifically questioned the vendoring changes that added that commit, in hashicorp/consul#4412 (comment).

(I assume that @MagnumOpus21 pulled in the fork by accident.)

That just goes to show the value of module paths and version tags, I suppose. 🙂

[MagnumOpus21]

I don't know what I did to cause this. Every time I would open a PR on the hashicorp repo, I would push commits to my own repo and then open a PR to merge them. I just followed govendor's FAQ for modifying the vendor file. Hope this throws some light on this issue.

[mitchellh]

No problem. Thanks for clarifying @bcmills we probably just got a weird commit into the vendor.