[pritambaral]

> Go’s module system should not have to give consideration to the particular transport you want to use.

> Its references are canonical and it’s up to you to set up the relevant process for it to retrieve the source for those references.

Git has a proper notion of references; it properly separates transport from references of remotes. Go uses just `https://` links, and expects the website to have a single `<meta>` tag containing a vcs clone URL (i.e., transport) to use. VCSes have had separation and multiplicity of transport for a long time, but Go will deal with only one URL (i.e., transport), with no way for the user/distributor to specify preferences otherwise.

For example, everything from git.kernel.org to github.com allows the user to chose which URL to clone with. The remote is not supposed to know or dictate a single transport.

I think `go get`'s limited method of transport discovery is just a hack that got released into production and stagnated in its form. It was a perfectly fine hack for public repos (on the internet or on Google's intranet), but it just never got any features (let alone documentation) specifically for repos that need an authenticated way to clone them. The fact that git has a nifty way to rewrite URLs is just a luck.

[BillinghamJ]

Bear in mind, Go doesn't just support git... so HTTP and SSH aren't the only options.

[pritambaral]

> Go doesn't just support git

I didn't claim Go supports only git.

> so HTTP and SSH aren't the only options.

My entire point is that VCSes support multiple transports since before Go came about. I never claimed Go should support HTTP and SSH only. In fact, I never claimed it should support either. I claimed it shouldn't force the VCS host to chose for the user which clone URL (and thus transport) to use.