list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Jeff King <>
To: Josh Triplett <>
Subject: Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?
Date: Fri, 19 Aug 2016 09:47:06 -0400
Message-ID: <> (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

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

> 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.


      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 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:

  List information:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone