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

From: Drew DeVault <sir@cmpwn.com>
Date: Mar 15, 2021, 18:14 UTC
Message-ID: <C9Y4NXXX6HRI.1IROIK8ZXK4S2@taiga>
In-Reply-To: <YE+ftT2WaKDzc+45@google.com>

On Mon Mar 15, 2021 at 1:56 PM EDT, Jonathan Nieder wrote:

Show 6 quoted lines

> 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 was indeed the original idea, but I think it's fair to assume that it's evolved well beyond this. There are many schemes in common use which don't meet this criteria, such as mailto:, magnet:, bitcoin:, postgresql:, and so on. None of these examples make productive use of all of the URI, such as your fragment example, but they still make productive use of parts of the URI.

To my mind, the contemporary purpose of a URI is to:

1. Identify a resource
2. Identify the protocol used to access it
3. Store domain-specific information that an implementation of that
   protocol can use to accomplish something

> 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.

I don't agree that this is the case. It would be much better to be able to identify a URL as being useful for git without having to perform a network request to find out.

A standard approach to the go-import kind of deal is also a meritous idea, but a separate matter - and one I'm also involved in trying to address!