From: Junio C Hamano <firstname.lastname@example.org> To: Jeff King <email@example.com> Cc: Drew DeVault <firstname.lastname@example.org>, Jonathan Nieder <email@example.com>, "brian m. carlson" <firstname.lastname@example.org>, email@example.com Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols Date: Thu, 18 Mar 2021 14:30:45 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YFEh2LxvsSPemail@example.com> (Jeff King's message of "Tue, 16 Mar 2021 17:23:36 -0400") Jeff King <firstname.lastname@example.org> writes: > So you definitely need to "somehow" know that a URL is meant to be used > with Git. And that makes me somewhat sympathetic to your request. Nicely summarized. I am also sympathetic to the cause, but I do not see upside in tucking the information to the URL syntax. Even if we limit ourselves to the CI context, I do not see how the repository location alone is sufficient (e.g. "build the tip of this branch of that repository every time it gets updated" already needs more than the repository location). > The downsides I see are: > > - one of the advantages of straight http:// URLs is that they can > accessed by multiple tools. Most "forge" tools let you use the same > URL both for getting a human-readable page in a browser, as well as > accessing the repository with the Git CLI. I'd hate to see https+git > URLs become common, because they add friction there (though simply > supporting them at all gives people the choice of whether to use > them). > > - I'm also sympathetic to brian's point that there's a wider > ecosystem. It's not just "git" that needs to learn them. It's jgit, > and libgit2, and many tools that work with git remotes. Yup.
next prev parent reply other threads:[~2021-03-18 21:31 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 [this message] 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 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).