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

From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Eli Schwartz <eschwartz@archlinux.org>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Drew DeVault <sir@cmpwn.com>,
	git@vger.kernel.org
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Tue, 16 Mar 2021 11:54:56 +0000	[thread overview]
Message-ID: <YFCckC8fHmEyOAnp@camp.crustytoothpaste.net> (raw)
In-Reply-To: <40740478-8b3c-b33e-8bb4-a2d68b83d385@archlinux.org>

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

On 2021-03-16 at 04:38:08, Eli Schwartz wrote:
> Why does this even matter? Again, the point here is the assertion by
> Drew that, for the purpose of listing a manifest of remotely fetchable
> resources, he sees a benefit to having some standard format for the URI
> itself, describing how it's intended to be fetched.
> 
> - ftp:// -> use the `ftp` tool
> - scp:// -> use the `scp` tool
> - http:// -> use the `wget` tool
> - git+http:// -> use the `git` tool
> 
> But instead of needing every program with a git integration to
> reimplement "recognize git+http and do substring prefix removal before
> passing to git", the suggestion is for git to do this.

I believe this construct is nonstandard.  It is better to use standard
URL syntax when possible because it makes it much, much easier for
people to use standard tooling to parse and handle URLs.  Such tooling
may have special cases for the HTTP syntax that it doesn't use in MAILTO
syntax, so it's important to pick something that works automatically.

It's difficult enough to handle parsing of SSH specifications and
distinguish them uniformly from Windows paths (think of an alias named
"c"), so I'd prefer we didn't add additional complexity to handle this
case.

Lest you think that only Git has to handle parsing these, the Git LFS
project (and every other implementation compatible with Git) has to
handle parsing them as well (and related things like url.*.insteadOf),
and providing bug-for-bug compatible behavior is generally a hassle.
We've run into numerous problems where things aren't exactly the same,
and making things more complex by adding an esoteric syntax that few
users are likely to use isn't helping.  Despite the fact that ssh+git is
specified as deprecated, we had people expect it to magically work and
had to support it in Git LFS.

So I'm very much opposed to adding, expanding, or giving any sort of
official blessing to this syntax, especially when there are perfectly
valid and equivalent schemes that are already blessed and registered
with IANA.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]