Skip to content
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.

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

cmd/go: 'go get […]/v2@v2.X.Y' fails when the go.mod file for […]/v2 is at the repo root [1.13 backport] #34497

gopherbot opened this issue Sep 24, 2019 · 2 comments


Copy link

@gopherbot gopherbot commented Sep 24, 2019

@bcmills requested issue #34383 to be considered for backport to the next 1.13 minor release.

@gopherbot, please backport to 1.13. This is a regression, and the workaround (editing the go.mod file instead of using go get) does not work for downgrading.

@gopherbot gopherbot added this to the Go1.13.1 milestone Sep 24, 2019
@bcmills bcmills changed the title cmd/go: go mod v2.* tags conflict with v2 branch causing go get to fail [1.13 backport] cmd/go: 'go get […]/v2@v2.X.Y' fails when the go.mod file for […]/v2 is at the repo root [1.13 backport] Sep 24, 2019
@bcmills bcmills self-assigned this Sep 24, 2019

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Sep 24, 2019

Change mentions this issue: [release-branch.go1.13] cmd/go: suppress errors in package-to-module queries if the package is already found


This comment has been minimized.

Copy link

@gopherbot gopherbot commented Sep 25, 2019

Closed by merging 1dc1e7c to release-branch.go1.13.

@gopherbot gopherbot closed this Sep 25, 2019
gopherbot pushed a commit that referenced this issue Sep 25, 2019
…queries if the package is already found

In CL 173017, I changed the package-to-module query logic to query all
possible module paths in parallel in order to reduce latency. (For
long package paths, most such paths will not exist and will fail with
little overhead.)

The module resolution algorithm treats various kinds of non-existence
as “soft errors”, to be reported only if package resolution fails, but
treats any remaining errors as hard errors that should fail the query.

Unfortunately, that interacted badly with the +incompatible version
validation added in CL 181881, causing a regression in the 'direct'
fetch path for modules using the “major branch” layout¹ with a post-v1
version on the repository's default branch. Because we did not
interpret a mismatched module path as “no such module”, a go.mod file
specifying the path '' would cause the search for
module '' to error out. (That regression was not caught
ahead of time due to a lack of test coverage for 'go get' on a package
within a /vN module.)

The promotion of hard errors during parallel search also made the 'go'
command less tolerant of servers that advertise 'go-import' tags for
nonexistent repositories. CL 194561 mitigated that problem for HTTP
servers that return code 404 or 410 for a nonexistent repository, but
unfortunately a few servers in common use (notably GitLab and
pre-1.9.3 releases of Gitea) do not.

This change mitigates both of those failure modes by ignoring
“miscellaneous” errors from shorter module paths if the requested
package pattern was successfully matched against a module with a
longer path.


Updates #34383
Updates #34094
Fixes #34497
Fixes #34215

Change-Id: If37dc422e973eba13f3a3aeb68bc7b96e2d7f73d
Run-TryBot: Bryan C. Mills <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Jay Conrod <>
(cherry picked from commit a3426f2)
@bcmills bcmills modified the milestones: Go1.13.1, Go1.13.2 Sep 25, 2019
@katiehockman katiehockman modified the milestones: Go1.13.2, Go1.13.3 Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.