From: "Drew DeVault" <firstname.lastname@example.org> To: "brian m. carlson" <email@example.com>, "Eli Schwartz" <firstname.lastname@example.org> Cc: "Jonathan Nieder" <email@example.com>, <firstname.lastname@example.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.
next prev parent 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 \ --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).