Go: cmd/go: go get package@branch fails after upgrading to 1.13

[jgimeno]

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

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

This happened to me since updating to 1.13.

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

go env Output

$ go env

GO111MODULE=""

GOARCH="amd64"

GOBIN="/Users/jgimeno/go/bin"

GOCACHE="/Users/jgimeno/Library/Caches/go-build"

GOENV="/Users/jgimeno/Library/Application Support/go/env"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GONOPROXY=""

GONOSUMDB=""

GOOS="darwin"

GOPATH="/Users/jgimeno/go"

GOPRIVATE=""

GOPROXY="https://proxy.golang.org,direct"

GOROOT="/usr/local/Cellar/go/1.13/libexec"

GOSUMDB="sum.golang.org"

GOTMPDIR=""

GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"

GCCGO="gccgo"

AR="ar"

CC="clang"

CXX="clang++"

CGO_ENABLED="1"

GOMOD=""

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/lr/20v7hz1j5cnfrzxlyw47bw5r0000gn/T/go-build161717808=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go get package@branch

What did you expect to see?

I would like to pull the branch dependency.

What did you see instead?

invalid: disallowed version string

[odeke-em]

Thank you for reporting this issue @jgimeno! Could you please give more detail and perhaps a minimal reproduction for issue? That will help make it actionable and easy for folks to diagnose what's going wrong.

Thank you.

[odeke-em]

/cc @bcmills @jayconrod

[jgimeno]

Hi! I haven't time to isolate it in some dummy project from scratch. But the idea is this one.

With version 1.12 in a project I could add a dependency on an external project that still was not merged in a branch lets say "theBranch".

So in the main project I could do go get github.com/therepo@theBranch, but if I do it in version 1.13 it fails with that error "invalid: disallowed version string".

I dont know if making it in a new project, empty with another project as the "branch" project would work, but in my case this is what happened. Now I have returned to 1.12 and I could go get the dependency by branch.

[cryptix]

I've hit the same issue. For me it happens when having slashes in the branch name like wip/thing. Just rolled back and it workes under 1.12.9.

[dolmen]

Workaround: use the commit hash instead of the branch name. You can use git rev-parse to resolve a branch name to a commit hash.

[hyangah]

The case @cryptix encountered seems like a duplicate of #32955. The workaround @dolmen suggested may work.

I can't say @jgimeno's case is identical without the exact branch name or the full error message now. But I am guessing that's similar. If the module version in the branch is not meant to be publicly available yet, how about bypassing Go module mirror and the global checksum db by specifying in GOPRIVATE. https://golang.org/doc/go1.13#modules ?

[hyangah]

@jgimeno can you please check if your case matches #32955 and we can mark this as a duplicate?

[jgimeno]

I don't think is the same issue, at least not directly. That issue has this information on the go.mod.

Mine is simpler, if I do go get github.com/thepackage@feature-branch it fails with 1.13, and with 1.12 did not fail (confirmed).

That go get, if is interesting to note generates a line in go.mod that looks like this (did not mention anything about @feature-branch name).

github.com/thepackage v0.0.0-20190908142153-4af4bbb049b2

[hyangah]

@jgimeno Thanks. Do you mind sharing the exact version string that caused the problem (was it literally "feature-branch"? And, also can you try go1.13 with GOPROXY=direct?

[jgimeno]

go get github.com/jgimeno/cloud-api@feature/create-transactions-bindings

About the GOPROXY=direct I will test soon today.

[bcmills]

@jgimeno, the slash within the branch name confirms that your issue is also #32955.

[bcmills]

Duplicate of #32955