]> Cypherpunks repositories - gostls13.git/commit
cmd/go: update TestGoGetUpdateWithWildcard expected behavior
authorRuss Cox <rsc@golang.org>
Sat, 18 Aug 2018 01:10:19 +0000 (21:10 -0400)
committerRuss Cox <rsc@golang.org>
Sat, 18 Aug 2018 03:02:40 +0000 (03:02 +0000)
commit714c141c4f2db626ea470a27cfd35f86b0c77c07
treec21aa9e8345f5d367adb459d3048478e2ab71101
parent850c964be21d8aadcb0c79be89e62762b0604fbf
cmd/go: update TestGoGetUpdateWithWildcard expected behavior

If you run

go get -u github.com/rsc/foo/bar...

then the go get command has always worked hard to make sure
that it applies the wildcard after downloading rsc/foo.
(If it applied the wildcard only before downloading rsc/foo,
it would match nothing if you had an empty GOPATH before,
and you'd still have an empty afterward, which is clearly useless.)

The goal has always been that if you run the same go get
command twice, the second command doesn't find anything
new to do.

CL 19892 worked around an "internal error" failure but broke
the rule about the first command doing everything the second
command would. Suppose you had github.com/rsc/foo already,
with just github.com/rsc/foo/bar, and you run

go get -u github.com/rsc/...

The wildcard first matches github.com/rsc/foo/bar, but suppose
updating the repo pulls down github.com/rsc/foo/baz, which
in turn depends on the non-existent package github.com/rsc/quux.
We need to reevaluate the wildcard after the download.

The new pattern match refactoring makes this easier and happened
to have corrected the behavior, but we missed a long test that
expected the old behavior.

Fix that long test.

Change-Id: I088473e7a90925e5c0f9697da9554a11456ddd08
Reviewed-on: https://go-review.googlesource.com/129796
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
src/cmd/go/go_test.go