git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Eli Schwartz <eschwartz@archlinux.org>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Drew DeVault <sir@cmpwn.com>,
	git@vger.kernel.org
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Tue, 16 Mar 2021 11:54:56 +0000	[thread overview]
Message-ID: <YFCckC8fHmEyOAnp@camp.crustytoothpaste.net> (raw)
In-Reply-To: <40740478-8b3c-b33e-8bb4-a2d68b83d385@archlinux.org>

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

On 2021-03-16 at 04:38:08, Eli Schwartz wrote:
> Why does this even matter? Again, the point here is the assertion by
> Drew that, for the purpose of listing a manifest of remotely fetchable
> resources, he sees a benefit to having some standard format for the URI
> itself, describing how it's intended to be fetched.
> 
> - ftp:// -> use the `ftp` tool
> - scp:// -> use the `scp` tool
> - http:// -> use the `wget` tool
> - git+http:// -> use the `git` tool
> 
> But instead of needing every program with a git integration to
> reimplement "recognize git+http and do substring prefix removal before
> passing to git", the suggestion is for git to do this.

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

Lest you think that only Git has to handle parsing these, the Git LFS
project (and every other implementation compatible with Git) has to
handle parsing them as well (and related things like url.*.insteadOf),
and providing bug-for-bug compatible behavior is generally a hassle.
We've run into numerous problems where things aren't exactly the same,
and making things more complex by adding an esoteric syntax that few
users are likely to use isn't helping.  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.

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.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

  reply	other threads:[~2021-03-16 11:56 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 [this message]
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
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=YFCckC8fHmEyOAnp@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=eschwartz@archlinux.org \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sir@cmpwn.com \
    --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).