Comment 1:

After digging around and trying various combinations out with combinations of servers,
https / http / git / git+ssh seem to be the only combination that works when thrown
after a http, git and git+ssh-server, respectively.
I have submitted a patch to that effect at https://golang.org/cl/14026043/

Comment 2:

I'm not sure we *want* to support this. On Windows,":" is a special character that
cannot appear in file names[1]. And on Unix machines it has a different meaning as a
path list separator. I don't want to see import paths with ":port" in them.
If you do need to serve content on a non-standard port, you should use the go-import
META tag trick[2].
1. http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
2. http://golang.org/cmd/go/#hdr-Remote_import_path_syntax

Status changed to Thinking.

Comment 3:

Hadn't thought of the resulting path validity issues. Bugger.
I ran into this bug while experimenting with a 'go get' proxy with some
git-versioning-trickery, so I can get consistent builds. Using standard ports means
running my test-code as root, which I don't particularly fancy.
Secondly, it might be considered a security-issue that it tries out non-secure options
(that even defaults to a non-privileged port) before at least attempting over a secure
protocol.

Comment 4:

"go get" doesn't have to be the be-all end-all here. Just write a tool that produces the
tree you need.
That's true about the insecurity angle. We should probably try https first.

Comment 5:

Labels changed: added go1.3maybe.

Comment 6:

Labels changed: added release-none, removed go1.3maybe.

Comment 7:

Labels changed: added repo-main.

Comment 8:

CL https://golang.org/cl/14026043 references this issue.

Comment 9:

CL https://golang.org/cl/14026043 references this issue.

Seem to be irrelevant now go get -insecure is a thing.

(Haven't looked much at the code or docs; just figured this might be cleanup-worthy now.)

Edit: From the discussion over at #9637, this definitely looks obsolete.