git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Drew DeVault" <sir@cmpwn.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Eli Schwartz" <eschwartz@archlinux.org>,
	"Jonathan Nieder" <jrnieder@gmail.com>, <git@vger.kernel.org>
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Thu, 18 Mar 2021 08:53:26 -0400	[thread overview]
Message-ID: <CA0HPQR98MZ8.HAL8GQYQ7QLD@taiga> (raw)
In-Reply-To: <YFJ9dI96TO5IdGRZ@camp.crustytoothpaste.net>

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.

  reply	other threads:[~2021-03-18 12:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 16:27 Drew DeVault
2021-03-15 17:56 ` Jonathan Nieder
2021-03-15 18:14   ` Drew DeVault
2021-03-15 22:01     ` brian m. carlson
2021-03-16  0:52       ` Drew DeVault
2021-03-16  1:02         ` Jonathan Nieder
2021-03-16  1:05           ` Drew DeVault
2021-03-16 21:23             ` Jeff King
2021-03-17 14:49               ` Drew DeVault
2021-03-18 21:30               ` Junio C Hamano
2021-03-18 21:53                 ` Drew DeVault
2021-03-16  4:38           ` Eli Schwartz
2021-03-16 11:54             ` brian m. carlson
2021-03-16 14:21               ` Drew DeVault
2021-03-16 21:28                 ` Jeff King
2021-03-17 14:50                   ` Drew DeVault
2021-03-17  0:45                 ` Jakub Narębski
2021-03-17 14:53                   ` Drew DeVault
2021-03-17 22:06                 ` brian m. carlson
2021-03-18 12:53                   ` Drew DeVault [this message]
2021-03-16 18:03               ` Eli Schwartz
2021-03-17 22:15                 ` Jonathan Nieder
2021-03-31  4:23                   ` Eli Schwartz
2021-04-07 13:46                   ` Mark Lodato
2021-04-07 19:46                     ` Junio C Hamano
2021-04-13  8:52                       ` Kerry, Richard
2021-03-16  0:54       ` Drew DeVault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA0HPQR98MZ8.HAL8GQYQ7QLD@taiga \
    --to=sir@cmpwn.com \
    --cc=eschwartz@archlinux.org \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    --subject='Re: Regarding the depreciation of ssh+git/git+ssh protocols' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).