git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Drew DeVault <sir@cmpwn.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>, git@vger.kernel.org
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Mon, 15 Mar 2021 22:01:46 +0000	[thread overview]
Message-ID: <YE/ZSiuIsMs3ucVM@camp.crustytoothpaste.net> (raw)
In-Reply-To: <C9Y4NXXX6HRI.1IROIK8ZXK4S2@taiga>

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On 2021-03-15 at 18:14:31, Drew DeVault wrote:
> On Mon Mar 15, 2021 at 1:56 PM EDT, Jonathan Nieder wrote:
> > 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.
> 
> I don't agree that this is the case. It would be much better to be able
> to identify a URL as being useful for git without having to perform a
> network request to find out.

But you can't find whether a URL is useful for a particular purpose in
general.  For example, if I see an HTTPS URL, that tells me nothing
about the resources that one might find at that URL.

One might find:

* A plain dumb Git remote.
* A plain smart Git remote.
* A smart Git remote and Git LFS support.
* A human-readable text response.
* A machine-readable JSON response.
* A binary document which is intended to be human intelligible.
* Something else.
* Nothing at all.

In addition, it's possible that the data you want exists, but is not
suitable for you in whatever way (not in a language you understand, in
an unsuitable format, is illegal or offensive, etc.), or you are not
authorized to access it.  You can't know any of this without making some
sort of request.

All a URL can tell you is literally where a resource is located.  Even
if we saw a URL that used the hypothetical https+git as the scheme, we
couldn't determine whether we could access the data, whether the data
even still exists, or, even if we knew all of those things, whether it
was using the smart or dumb protocol, without making a request.

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.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  reply	other threads:[~2021-03-15 22:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 16:27 Regarding the depreciation of ssh+git/git+ssh protocols Drew DeVault
2021-03-15 17:56 ` Jonathan Nieder
2021-03-15 18:14   ` Drew DeVault
2021-03-15 22:01     ` brian m. carlson [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2023-10-13 20:49 David Rogers

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/ZSiuIsMs3ucVM@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sir@cmpwn.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).