git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Drew DeVault <sir@cmpwn.com>
Cc: git@vger.kernel.org
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Mon, 15 Mar 2021 10:56:05 -0700	[thread overview]
Message-ID: <YE+ftT2WaKDzc+45@google.com> (raw)
In-Reply-To: <C9Y2DPYH4XO1.3KFD8LT770P2@taiga>

Hi,

Drew DeVault wrote:

> c05186cc38ca4605bff1f275619d7d0faeaf2fa5 introduced ssh+git, and
> 07c7782cc8e1f37c7255dfc69c5d0e3f4d4d728c admitted this was a mistake. I
> argue that it was not a mistake.
>
> The main use-case for the git-specific protocol is to disambiguate with
> other version control systems which also use SSH (or HTTPS), such as
> Mercurial, or simply downloading a tarball over HTTP.

Following the trail of links, I reach
https://public-inbox.org/git/CA+55aFyWqK0bu2V1SYagrYCBGpj0=2orobK2vT-KRkqpq=kgtw@mail.gmail.com/,
but that email mostly just makes assertions rather than explaining the
rationale.  So it's probably worth talking it through now.

> Some things that are affected by this include package manager source
> lists and configurations for CI tooling (the latter being my main
> interest in this).

The original idea of URI schemes like svn+https is that we can treat
these version control URLs as part of the general category of uniform
resource identifiers --- in other words, you might be able to type
them in a browser's URL bar, browse the content of a repository, use
an <img> tag to point to a file within a version control repository,
and so on.

_That_ idea, at least, does not work all that well.  There's not an
equivalent to a fragment identifier to refer to a particular file
within a repository.  Further, if I have an https URL referring to a
Git repository, I'm better off viewing it without a "git+" prefix
because then I can see the content of the repository using a web based
repository browser.

In other words, a "Git URL" is not a URI at all; it's simply the
identifier that Git uses to clone a repository.  A package manager or
CI tool is perfectly within its rights to provide its own naming
scheme for sources, such as "git::https://example.com/path/to/repo" or
even the same with "git+" prefix; or it can use an https URL and infer
from the content it gets there what version control system it uses.

The missing piece is an HTTP header to unambiguously mark that URL as
being usable by Git.  I'm not aware of a standard way to do that; e.g.
golang's "go get" tool[*] uses a custom 'meta name="go-import"' HTML
element.

Thanks and hope that helps,
Jonathan

[*] https://golang.org/cmd/go/#hdr-Remote_import_paths

  reply	other threads:[~2021-03-15 17:57 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 [this message]
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
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=YE+ftT2WaKDzc+45@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sir@cmpwn.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).