list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Jakub Narębski" <>
To: "Drew DeVault" <>
Cc: "brian m. carlson" <>,
	"Eli Schwartz" <>,
	"Jonathan Nieder" <>, <>
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Wed, 17 Mar 2021 01:45:09 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <C9YUBUYH7PWU.3PHDZR2YCUEOX@taiga> (Drew DeVault's message of "Tue, 16 Mar 2021 10:21:13 -0400")

"Drew DeVault" <> writes:
> 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.

All right, that is true... but the Git itself and Git--related tools do
not usually employ the full-fledged URI parser, as far as I know.  They
just check for the few schemas they support if the repository location
is given as an URI / URL.

That said, if the RFC states it, then it is a standard construct.

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

Well, thara is a total of one protocol (CoAP) that uses '+' based
schemas, namely: coap+tcp, coap+ws, coaps+tcp, coaps+ws (well at least
out of those protocols that made it into IANA).

Though it in this case neither of those parts of schema joined by the
'+' sign is an application name...

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

The Git documentation explicitly enumerates all possible URL types that
you can use with Git.

On the other hand Git-related tools can support more types of URL, for
example ones for AWS S3 buckets.

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

To reiterate, the idea of "prefixed URLs", that is using git+https://
and git+ssh:// is to denote that said URL is only usable by Git, without
any additional out-of-band information (like other attributes on <a>
element or its encompassing element)?

Jakub Narębski

  parent reply	other threads:[~2021-03-17  0:47 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 [this message]
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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: Regarding the depreciation of ssh+git/git+ssh protocols' \

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

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