From: "Drew DeVault" <email@example.com> To: "brian m. carlson" <firstname.lastname@example.org> Cc: "Eli Schwartz" <email@example.com>, "Jonathan Nieder" <firstname.lastname@example.org>, <email@example.com> Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols Date: Thu, 18 Mar 2021 08:53:26 -0400 [thread overview] Message-ID: <CA0HPQR98MZ8.HAL8GQYQ7QLD@taiga> (raw) In-Reply-To: <YFJ9dI96TO5IdGRZ@camp.crustytoothpaste.net> I feel like the tone here is getting a bit hostile. Let's try to keep things friendly. On Wed Mar 17, 2021 at 6:06 PM EDT, brian m. carlson wrote: > 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 > so. > > 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. This is a needlessly high bar to set, and saying we can only proceed with the IANA's involvement seems like a convenient excuse to shut the conversation down entirely. Registering with IANA is nice, but there are thousands of protocols which don't bother. In any case, this is not quite as high of a bar as you may believe (or hope?). The process is pretty straightforward, and a scheme with "+" in it meets the criteria laid forth in the RFC, and the argument is even stronger given that WHATWG standards make use of the convention these days. If this is truly desirable, we can do it after the feature lands, but given that the git:// protocol was registered as an apparent after-thought by a third-party from Microsoft with zero commits in the git tree, it just seems like a requirement put forth in bad faith. > > > 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. What third-party software do you represent? Can we make an objective estimation of the complexity of the change for your project in practice? > Adding this feature which duplicates existing functionality What existing method is there to identify a URL as being a git remote? > 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. As you explained, this confusion is already happening. If users don't know what a URI is, then they're already confused, and this is unlikely to make it worse. If anything, this could make it easier, as a URL which explicitly represents its relationship with git could hint at its intended usage. And again, I don't expect users to actually be handing these URLs around to each other for regular use. This is specifically necessary in cases where software needs to handle multiple kinds of version control.
next prev parent reply other threads:[~2021-03-18 12:54 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 2021-03-18 12:53 ` Drew DeVault [this message] 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=CA0HPQR98MZ8.HAL8GQYQ7QLD@taiga \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).