# Both example.net/ambiguous v0.1.0 and example.net/ambiguous/pkg v0.1.0 exist.
# 'go mod tidy' would arbitrarily choose the one with the longer path,
# but 'go mod tidy' also arbitrarily chooses the latest version.

cp go.mod go.mod.orig


# From a clean slate, 'go get' currently does the same thing as 'go mod tidy':
# it resolves the package from the module with the longest matching prefix.

go get -d example.net/ambiguous/nested/pkg@v0.1.0
go list -m all
stdout '^example.net/ambiguous/nested v0.1.0$'
! stdout '^example.net/ambiguous '


# From an initial state that already depends on the shorter path,
# the same 'go get' command attempts to add the longer path and fails.
#
# TODO(bcmills): What should really happen here?
# Should we match the versioned package path against the existing package
# (reducing unexpected errors), or give it the same meaning regardless of the
# initial state?

cp go.mod.orig go.mod
go mod edit -require=example.net/ambiguous@v0.1.0

! go get -d example.net/ambiguous/nested/pkg@v0.1.0
stderr '^go get example.net/ambiguous/nested/pkg@v0.1.0: ambiguous import: found package example.net/ambiguous/nested/pkg in multiple modules:\n\texample.net/ambiguous v0.1.0 \(.*\)\n\texample.net/ambiguous/nested v0.1.0 \(.*\)\n\z'


# The user should be able to fix the aforementioned failure by explicitly
# upgrading the conflicting module.

go get -d example.net/ambiguous@v0.2.0 example.net/ambiguous/nested/pkg@v0.1.0
go list -m all
stdout '^example.net/ambiguous/nested v0.1.0$'
stdout '^example.net/ambiguous v0.2.0$'


# ...or by explicitly NOT adding the conflicting module.
#
# BUG(#37438): Today, this does not work: explicit module version constraints do
# not affect the package-to-module mapping during package upgrades, so the
# arguments are interpreted as specifying conflicting versions of the longer
# module path.

cp go.mod.orig go.mod
go mod edit -require=example.net/ambiguous@v0.1.0

! go get -d example.net/ambiguous/nested/pkg@v0.1.0 example.net/ambiguous/nested@none
stderr '^go get: conflicting versions for module example.net/ambiguous/nested: v0.1.0 and none$'

 # go list -m all
 # ! stdout '^example.net/ambiguous/nested '
 # stdout '^example.net/ambiguous v0.1.0$'


# The user should also be able to fix it by *downgrading* the conflicting module
# away.
#
# BUG(#37438): Today, this does not work: the "ambiguous import" error causes
# 'go get' to fail before applying the requested downgrade.

cp go.mod.orig go.mod
go mod edit -require=example.net/ambiguous@v0.1.0

! go get -d example.net/ambiguous@none example.net/ambiguous/nested/pkg@v0.1.0
stderr '^go get example.net/ambiguous/nested/pkg@v0.1.0: ambiguous import: found package example.net/ambiguous/nested/pkg in multiple modules:\n\texample.net/ambiguous v0.1.0 \(.*\)\n\texample.net/ambiguous/nested v0.1.0 \(.*\)\n\z'

 # go list -m all
 # stdout '^example.net/ambiguous/nested v0.1.0$'
 # !stdout '^example.net/ambiguous '


# In contrast, if we do the same thing tacking a wildcard pattern ('/...') on
# the end of the package path, we get different behaviors depending on the
# initial state, and no error. (This seems to contradict the “same meaning
# regardless of the initial state” point above, but maybe that's ok?)

cp go.mod.orig go.mod

go get -d example.net/ambiguous/nested/pkg/...@v0.1.0
go list -m all
stdout '^example.net/ambiguous/nested v0.1.0$'
! stdout '^example.net/ambiguous '


cp go.mod.orig go.mod
go mod edit -require=example.net/ambiguous@v0.1.0

go get -d example.net/ambiguous/nested/pkg/...@v0.1.0
go list -m all
! stdout '^example.net/ambiguous/nested '
stdout '^example.net/ambiguous v0.1.0$'


-- go.mod --
module test

go 1.16