git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eli Schwartz <eschwartz@archlinux.org>
To: Jonathan Nieder <jrnieder@gmail.com>, Drew DeVault <sir@cmpwn.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Regarding the depreciation of ssh+git/git+ssh protocols
Date: Tue, 16 Mar 2021 00:38:08 -0400	[thread overview]
Message-ID: <40740478-8b3c-b33e-8bb4-a2d68b83d385@archlinux.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 --]

  parent reply	other threads:[~2021-03-16  4:39 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
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
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40740478-8b3c-b33e-8bb4-a2d68b83d385@archlinux.org \
    --to=eschwartz@archlinux.org \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    --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.
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 NNTP newsgroup(s).