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

[Eli Schwartz <eschwartz@archlinux.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2736 bytes --]

On 3/16/21 7:54 AM, brian m. carlson wrote:
> 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.

Suddenly I'm hearing a much more reasonable response than "but it
doesn't give me content-type so I can't know which media application is
capable of opening it".

(I'm not especially attached to the proposal. I'm a maintainer for one
of these package managers that currently special-case git+https?:// and
rewrite the url that git sees, which has worked adequately for a long
time. However, I figured if you want to reject this proposal, reject it
for a good reason...)

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]