> 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.
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.
It’s hardly magic. It’s a defined feature of git. If one couldn’t avail himself of the defined features of git, then there’d be no reason to build on top of it in the first place.
> If one couldn’t avail himself of the defined features of git, then there’d be no reason to build on top of it in the first place.
Sure build on top of it, but don't expect your users to implicitly know the defined, yet obscure, features of git you build on.
> It’s hardly magic.
I didn't claim this is a magic feature in git. I meant the way of `go get`-ing a private library by letting `go get` try and clone from https URLs while silently changing them to git:// URLs in a completely separate layer under it is magic.
How is the first application developer to know this git (not go) feature exists in the first place? The application developer is looking to use `go get`, and is frustrated that `go get` only downloads via https, asking them for a username and password combo every time. `go get` has no documentation to make it use git URLs.
Only when the application developer looks online for a solution to this do they find some StackOverflow post detailing this workaround. Or other workarounds, like the insecure option of telling git to save your https credentials.
Sure, a knowledgeable application developer can put whatever quirks their build system needs in their documentation; but a developer ignorant of these workarounds shouldn't have to go beyond `go get`'s documentation in the first place.
