cmd/go: 'go get' fails to track a branch which contains a /

[grellyd]

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

$ go version

go version go1.14.2 darwin/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=""
GOCACHE="/Users/grellyd/Library/Caches/go-build"
GOENV="/Users/grellyd/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY="go.company.io"
GONOSUMDB="go.company.io"
GOOS="darwin"
GOPATH="/Users/grellyd/wrk/go"
GOPRIVATE="go.company.io"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.2_1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.2_1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/grellyd/wrk/go/src/go.company.io/repo/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/34/mxhn7dp54z9fp1phcl1t0mr80000gn/T/go-build088434320=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I was attempting to test changes in a branch of a vendored dependency on a private repository. Having never done this before using go modules, I found the docs (https://golang.org/cmd/go/#hdr-Add_dependencies_to_current_module_and_install_them) which indicated I should go get the associated repo and have the default version overridden by adding an @version suffix to the package argument, as in 'go get golang.org/x/text@v0.3.0'.

I assumed from there that I should add the branch as the checkout point. This resulted in the error below, indicating the version string was disallowed. Our company namespaces our github branches before doing the proper branch name. For us, slashes in the branch name are a common workflow. We occasionally also use multiple sub-namespaces for organisation.

Upon further research, I found a docs issue (#30851), and an associated issue (#36902). After commenting on the final issue, I opened this one.

A workaround at this time is to git log the sha of the HEAD of the namespaced branch and then go get using that sha. EG: go get github.com/org/repo@sha

An ideal configuration would download new commits upon a subsequent go get, which the sha checkout would not.

What did you expect to see?

go get github.com/org/repo@namespace/branch downloading and checking out that go module at that branch sha.

What did you see instead?

go get github.com/org/repo@namespace/branch: github.com/org/repo@namespace/branch: invalid version: version "branch" invalid: disallowed version string

[thomaspeugeot]

notice that vscode default branch naming policy is with a slash, therefore, the issue is systematic with this configuration.

https://github.com/microsoft/vscode-pull-request-github/blob/main/package.json

		"githubIssues.issueBranchTitle": {
        			"type": "string",
        			"default": "${user}/issue${issueNumber}",
        		},

[andig]

I‘ve tried quoting the branch name, but that doesn‘t help either.

[tonglil]

See #32955

[mvdan]

Thank you @tonglil - this is indeed a duplicate of the older issue, which has had more discussion. My guess is that this issue got more thumbs up reactions because the title is closer to what the user's situation tends to be: git branches containing slashes.

I'm going to close this as a duplicate for now. For updates, please subscribe to #32955.

As a temporary workaround in case any of you are blocked, you can use GOPROXY=direct go get in the meantime. The bug is in the proxy.golang.org software, not in cmd/go itself.

[directionless]

Is it a dup? #32955 is focused on proxy behaviors. I'd swear I encountered this before the proxy

[mvdan]

I am pretty sure, and just ran a test:

$ go get mvdan.cc/garble@test/with/slashes
go: mvdan.cc/garble@test/with/slashes: invalid version: version "test/with/slashes" invalid: disallowed version string
$ GOPROXY=direct go get mvdan.cc/garble@test/with/slashes
go: downloading mvdan.cc/garble v0.7.1-0.20220711113617-8bc971e0a284

[grellyd]

Thanks for the link to the underlying issue @mvdan. For what it is worth, I never set GOPROXY myself: it remained the default value of GOPROXY="https://proxy.golang.org,direct".

Am I correct in understanding the workaround for this issue is to remove the Golang proxy from GOPROXY and instead only prefer direct? In other words, set GOPROXY=direct in our environment.

[mvdan]

Correct. Just don't set GOPROXY=direct permanently or globally, because that would greatly slow down Go modules in general.