git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Josh Triplett <josh@joshtriplett.org>
Cc: git@vger.kernel.org
Subject: Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?
Date: Fri, 19 Aug 2016 09:47:06 -0400	[thread overview]
Message-ID: <20160819134706.t2ejriomp3z3xqly@sigill.intra.peff.net> (raw)
In-Reply-To: <20160816222414.GA17195@cloud>

On Tue, Aug 16, 2016 at 03:24:14PM -0700, Josh Triplett wrote:

> > But if we had a real full-duplex connection over https, I think there
> > would be no reason for git:// to continue existing (we'd probably keep
> > ssh as it's a useful protocol for authentication, though).
> 
> Agreed.
> 
> Using ALPN wouldn't actually end up using HTTPS; it would negotiate with
> the server and end up connected directly to a git program speaking an
> arbitrary protocol over TLS.  Many web servers already support ALPN to
> negotiate HTTP/2, so this seems plausible.

It sounds like that would lose one of the nice properties of
git-over-http, which is that it works through arbitrary proxies (for
some people on restricted networks, they are stuck going through a
company-wide proxy, and neither git:// nor ssh are options in the first
place).

Maybe the world is heading in the direction of supporting ALPN
everywhere, but I suspect we'll be dealing with older proxies for a
while.

> Another alternative would be to define a framing for a full-duplex
> git-upload-pack connection inside a single HTTP/2 connection; HTTP/2
> already effectively allows full-duplex asynchronous conversations.

This has some of the same problem as above, though I'd bet on HTTP/2
support becoming mainstream more quickly.

I'm not very well educated on HTTP/2, but my understanding is that it
_doesn't_ just provide a full-duplex asynchronous connection out of the
box. You get "server push", but that is not quite the same thing.

So I'm not sure if we can make something work on top of those building
blocks, and if we do, how well it would fare with standard components
like proxies in the middle.

-Peff

      reply	other threads:[~2016-08-19 13:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 16:18 upload-pack/ls-remote: showing non-HEAD symbolic refs? Josh Triplett
2016-08-16 16:31 ` Jeff King
2016-08-16 17:34   ` Josh Triplett
2016-08-16 18:28     ` Jeff King
2016-08-16 18:50       ` Stefan Beller
2016-08-16 20:34         ` Josh Triplett
2016-08-16 20:31       ` Josh Triplett
2016-08-16 20:54         ` Jeff King
2016-08-16 21:11           ` Josh Triplett
2016-08-16 21:15             ` Jeff King
2016-08-16 22:24               ` Josh Triplett
2016-08-19 13:47                 ` Jeff King [this message]

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=20160819134706.t2ejriomp3z3xqly@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=josh@joshtriplett.org \
    /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).