-
Russ Cox authored
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>
714c141c