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>,
	"Eli Schwartz" <eschwartz@archlinux.org>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>, <git@vger.kernel.org>
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Tue, 16 Mar 2021 10:21:13 -0400	[thread overview]
Message-ID: <C9YUBUYH7PWU.3PHDZR2YCUEOX@taiga> (raw)
In-Reply-To: <YFCckC8fHmEyOAnp@camp.crustytoothpaste.net>

On Tue Mar 16, 2021 at 7:54 AM EDT, brian m. carlson wrote:
> 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 is standard - RFC 3986 section 3.1 permits the + character in
URI schemes. The use of protocol "composition", e.g. git+https, is a
convention, but not a standard.
>
> 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.

This convention is blessed by the IANA, given that they have
accepted protocol registrations which use this convention:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

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

There's no additional complexity here: git remotes are URIs, and any
implementation which parses them as such already deals with this case
correctly. Any implementation which doesn't may face all kinds of
problems as a consequence: SSH without a user specified, HTTPS with
Basic auth in the URI username/password fields (or just the password,
which is also allowed), and so on. Any sane and correct implementation
is pulling in a URI parser here, and if not, I don't think it's fair for
git to constrain itself in order to work around some other project's
bugs.

> 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 :)

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

Aye, people do expect it to work. The problem is not going to go away.

  reply	other threads:[~2021-03-16 14:22 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 [this message]
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
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=C9YUBUYH7PWU.3PHDZR2YCUEOX@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).