From: Eli Schwartz <email@example.com> To: Jonathan Nieder <firstname.lastname@example.org>, Drew DeVault <email@example.com> Cc: "brian m. carlson" <firstname.lastname@example.org>, email@example.com Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols Date: Tue, 16 Mar 2021 00:38:08 -0400 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YFADuptwV7iR76g5@google.com> [-- Attachment #1.1: Type: text/plain, Size: 2162 bytes --] On 3/15/21 9:02 PM, Jonathan Nieder wrote: > Drew DeVault wrote: >> On Mon Mar 15, 2021 at 6:01 PM EDT, brian m. carlson wrote: > >>> So I don't think this is a thing we can do, simply because in general >>> URLs aren't suitable for sharing this kind of information. >> >> That's simply not true. They are quite capable at this task, and are >> fulfilling this duty for a wide varitety of applications today. >> >> I don't really understand the disconnect here. No, URLs are not magic, >> but they are perfectly sufficient for this use-case. > > I'm not sure it's a disconnect; instead, it just looks like we > disagree. That said, with more details about the use case it might be > possible to sway me in another direction. > > To maintain the URI analogy: the URI does not tell me the content-type > of what I can access from there. Until I know that content-type, I > may not know what the best tool is to access it. This is a pretty odd argument. Drew is recommending that the URI "git+https://" tells a person the right tool to obtain the resource ("do I use curl/wget, or git clone"), and now you're arguing that that it is somehow insufficient because "git+https://" doesn't tell the person which media viewer application is best suited to display the contents after it's been downloaded and no longer has an associated URI at all (but does exchange that particular variety of metadata for a mimetype). 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. There is definitely a (strange) disconnect here. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-03-16 4:39 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 [this message] 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 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 \ --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).