The golang/lint bugs are often due to the move of x/tools from code.google.com to github. There is, of course, a general class of problems here to do with the use of vanity import paths, but the specific case of the Go subrepos is a particularly notable instance of that class, and I wonder if it would be worth explicitly checking for them in go get even if we don't try to solve the general class.

The wording is "By default, get uses..." (emphasis mine).

The -u flag instructs get to use the network to update the named packages
and their dependencies. By default, get uses the network to check out
missing packages but does not use it to look for updates to existing packages.

So go get -u updates the named packages and their deps. go get without the flag just downloads missing packages.

Note that it only updates the particular checkout of a package (e.g. approximately git pull); it doesn't "update" in the semantic sense if a vanity import path changes where it points.

@dsymonds hm, that seems like an oversight. We should probably print an error in that case.

Didn't f3a98de address the issue of vanity paths changing where they point?

I'm guessing f3a98de only checked the named package, not its dependencies.

"go get -u" does update existing packages. Maybe there is something wrong with something else. If so, please file a separate bug.