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

["Drew DeVault" <sir@cmpwn.com>]

I feel like the tone here is getting a bit hostile. Let's try to keep
things friendly.

On Wed Mar 17, 2021 at 6:06 PM EDT, brian m. carlson wrote:
> I assume that you're volunteering to write the RFC to register these
> with IANA? If not, then they are indeed non-standard and will remain
> so.
>
> I should point out that I don't believe the IANA will accept such a
> registration, because they will believe it to be duplicative of the
> existing scheme. But if you want to go this route, we should only
> proceed if we register them with IANA.

This is a needlessly high bar to set, and saying we can only proceed
with the IANA's involvement seems like a convenient excuse to shut the
conversation down entirely. Registering with IANA is nice, but there are
thousands of protocols which don't bother.

In any case, this is not quite as high of a bar as you may believe (or
hope?). The process is pretty straightforward, and a scheme with "+" in
it meets the criteria laid forth in the RFC, and the argument is even
stronger given that WHATWG standards make use of the convention these
days. If this is truly desirable, we can do it after the feature lands,
but given that the git:// protocol was registered as an apparent
after-thought by a third-party from Microsoft with zero commits in the
git tree, it just seems like a requirement put forth in bad faith.

> > > Lest you think that only Git has to handle parsing these
> > 
> > I don't, given that my argument stems from making it easier for
> > third-party applications to deal with git URIs :)
>
> This does not make my life as a maintainer of said third-party
> application easier. It complicates it significantly, because people
> often upgrade Git without upgrading Git LFS and then are unhappy when
> the five-year old version they use from their distro doesn't support
> every new feature.

What third-party software do you represent? Can we make an objective
estimation of the complexity of the change for your project in practice?

> Adding this feature which duplicates existing functionality

What existing method is there to identify a URL as being a git remote?

> It also will inevitably confuse users who will want to know the relevant
> difference between the URLs and which they should use. They will then
> see the new type of URL and wonder why it does not work with the version
> they are using. And many users already don't understand the difference
> between HTTPS and SSH URLs, which is compounded by the fact that many
> Windows users have never before and will never otherwise use SSH.

As you explained, this confusion is already happening. If users don't
know what a URI is, then they're already confused, and this is unlikely
to make it worse. If anything, this could make it easier, as a URL which
explicitly represents its relationship with git could hint at its
intended usage.

And again, I don't expect users to actually be handing these URLs around
to each other for regular use. This is specifically necessary in cases
where software needs to handle multiple kinds of version control.