proxy.golang.org: update to Go 1.13.3 to pick up the fix for #34477

[zikaeroh]

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

$ go version
go version go1.13.3 linux/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="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/jake/sdk/go1.13.3"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jake/sdk/go1.13.3/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/testproj/gopls-mod-bug/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build837848104=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ go mod init goplstest
$ go get golang.org/x/tools/gopls@master golang.org/x/tools@master

Repeat with and without GOPROXY=direct, and check go.mod.

What did you expect to see?

The same output with/without a proxy.

What did you see instead?

With the default:

module goplstest

go 1.13

require (
	golang.org/x/tools v0.0.0-20191018000036-341939e08647 // indirect
	golang.org/x/tools/gopls v0.0.0-20191018000036-341939e08647 // indirect
)

With GOPROXY=direct:

module goplstest

go 1.13

require (
	golang.org/x/tools v0.0.0-20191018000036-341939e08647 // indirect
	golang.org/x/tools/gopls v0.1.8-0.20191018000036-341939e08647 // indirect
)

Note the version differences in the last requirement line. I wrote a go/bin manager that manages tools via mod files as dotfiles, and this hits me when I sometimes set GOPROXY=direct and the versions I have change (even though there was no update).

[zikaeroh]

I think the gopherbot gopls title matcher needs a little work... 🙂

[heschi]

The go command uses the Git history to decide what version the pseudoversion should be based on, and it seems like doing tools/ and tools/gopls at the same time changes that result somehow. I don't know if this is a bug in the go command or maybe in Gerrit's unshallow implementation?

$ GOPATH=$(mktemp -d) GOPROXY=direct go get golang.org/x/tools/gopls@master
...
go: downloading golang.org/x/tools/gopls v0.0.0-20191018000036-341939e08647

$ GOPATH=$(mktemp -d) GOPROXY=direct go get golang.org/x/tools/gopls@master golang.org/x/tools@master
...
go: downloading golang.org/x/tools/gopls v0.1.8-0.20191018000036-341939e08647

proxy.golang.org downloads one thing at a time, so gets the former behavior.

@bcmills @jayconrod

[bcmills]

There is a bug in the git client itself, for which a workaround was backported in #34477.

Probably proxy.golang.org just needs to be upgraded to Go 1.13.3 to pick up the fix.
(@heschik, what go version were you using in #34991 (comment)?)

[zikaeroh]

Yeah, I hadn't tested this specifically without also getting x/tools itself, as gopls's master often fails to compile without its parent module also being at master (regardless of what its go.mod says is the minimum), and my goal is to get a working binary. Thanks for noticing that point, @heschik.

[bcmills]

Provisionally retitling to reflect the current working theory, but please do let me know if we find evidence that this is still an issue after 1.13.3.