list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <>
To: Drew DeVault <>
Cc: Eli Schwartz <>,
	Jonathan Nieder <>,
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Wed, 17 Mar 2021 22:06:44 +0000	[thread overview]
Message-ID: <> (raw)

[-- Attachment #1: Type: text/plain, Size: 4184 bytes --]

On 2021-03-16 at 14:21:13, Drew DeVault wrote:
> On Tue Mar 16, 2021 at 7:54 AM EDT, brian m. carlson wrote:
> > 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:

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

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.

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

We accept local paths in a variety of situations and SSH specifications,
neither of which are URLs.  The ultimate problem is that we support
Windows paths and need to handle them correctly on Windows but don't
support them on other operating systems and need to not handle them
there.  So, somehow, in portable code which does not vary based on
operating system, we need to decide what should be a local path and what
should be an SSH specification and do that in a way compatible with Git.

Git LFS has also run into the problem that the URL parser we use has
gotten stricter in a point release due to CVEs against it which broke
various kinds of parsing of our SSH URLs that were previously accepted.
This almost certainly bit other Go-based tools that work with Git
repositories as well, since everyone uses the standard library URI

If we only supported valid URLs, this would be much, much easier.  That
is not at all the case, and it has never been the case for Git.

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

Adding this feature which duplicates existing functionality does not
improve my life as a user of Git, as a developer of Git, as a maintainer
of a number of third-party tools which interact with Git, or as someone
who maintains part of a hosting platform.

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.

In case it was not already clear, I'm very strongly opposed to this
proposal.  It seems to make a lot of needless work without a clear and
convincing benefit.
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2021-03-17 22:07 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 [this message]
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).