From: "Jakub Narębski" <email@example.com> To: "Drew DeVault" <firstname.lastname@example.org> Cc: "brian m. carlson" <email@example.com>, "Eli Schwartz" <firstname.lastname@example.org>, "Jonathan Nieder" <email@example.com>, <firstname.lastname@example.org> Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols Date: Wed, 17 Mar 2021 01:45:09 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <C9YUBUYH7PWU.3PHDZR2YCUEOX@taiga> (Drew DeVault's message of "Tue, 16 Mar 2021 10:21:13 -0400") "Drew DeVault" <firstname.lastname@example.org> 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: > > https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 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)? Best, -- Jakub Narębski
next prev 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).