Re: Regarding the depreciation of ssh+git/git+ssh protocols

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 15, 2021, 17:56 UTC
Message-ID: <YE+ftT2WaKDzc+45@google.com>
In-Reply-To: <C9Y2DPYH4XO1.3KFD8LT770P2@taiga>

Hi,

Drew DeVault wrote:

Show 7 quoted lines

> c05186cc38ca4605bff1f275619d7d0faeaf2fa5 introduced ssh+git, and
> 07c7782cc8e1f37c7255dfc69c5d0e3f4d4d728c admitted this was a mistake. I
> argue that it was not a mistake.
>
> The main use-case for the git-specific protocol is to disambiguate with
> other version control systems which also use SSH (or HTTPS), such as
> Mercurial, or simply downloading a tarball over HTTP.

Following the trail of links, I reach https://public-inbox.org/git/CA+55aFyWqK0bu2V1SYagrYCBGpj0=2orobK2vT-KRkqpq=kgtw@mail.gmail.com/, but that email mostly just makes assertions rather than explaining the rationale. So it's probably worth talking it through now.

> Some things that are affected by this include package manager source
> lists and configurations for CI tooling (the latter being my main
> interest in this).

The original idea of URI schemes like svn+https is that we can treat these version control URLs as part of the general category of uniform resource identifiers --- in other words, you might be able to type them in a browser's URL bar, browse the content of a repository, use an <img> tag to point to a file within a version control repository, and so on.

_That_ idea, at least, does not work all that well. There's not an equivalent to a fragment identifier to refer to a particular file within a repository. Further, if I have an https URL referring to a Git repository, I'm better off viewing it without a "git+" prefix because then I can see the content of the repository using a web based repository browser.

In other words, a "Git URL" is not a URI at all; it's simply the identifier that Git uses to clone a repository. A package manager or CI tool is perfectly within its rights to provide its own naming scheme for sources, such as "git::https://example.com/path/to/repo" or even the same with "git+" prefix; or it can use an https URL and infer from the content it gets there what version control system it uses.

The missing piece is an HTTP header to unambiguously mark that URL as being usable by Git. I'm not aware of a standard way to do that; e.g. golang's "go get" tool[*] uses a custom 'meta name="go-import"' HTML element.

Thanks and hope that helps, Jonathan

[*] https://golang.org/cmd/go/#hdr-Remote_import_paths