mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Josh Triplett <>
Subject: Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?
Date: Tue, 16 Aug 2016 16:54:27 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20160816203150.GA16774@cloud>

On Tue, Aug 16, 2016 at 01:31:50PM -0700, Josh Triplett wrote:

> > You can dig up the discussion on the list under the name "protocol v2",
> > but basically yes, that approach has been considered. It's a little
> > gross just because it leaves other protocols behind http (and it is not
> > necessarily a good idea to push people into http, because it has some
> > fundamental drawbacks over the other protocols because of its
> > half-duplex nature).
> I looked through the "protocol v2" threads, but couldn't find any
> discussions of using HTTP headers.  I found some mentions of using
> additional query parameters on the git-upload-pack request, which would
> break compatibility with existing servers (they won't just ignore the
> extra parameter).

Probably the most interesting recent discussion is the sub-thread of
this patch:

which you might have missed because it only messages "v2 protocol" in
the body.

But basically, I think you get the gist of it. We need to pass
information from the client to the server _before_ the initial
capability advertisement. For HTTP, we can do it via specialized headers
or query parameters. For other protocols, we're stuck with some kind of
try-and-fallback hack.

That means those protocols may diverge slightly from HTTP, but at least
they would differ only in the "bootstrap v2" bit (and that would
eventually become irrelevant as everybody moves to v2).

> --client-caps could work for SSH as well, it just requires an extra
> round-trip to check for --client-caps.  Call git-upload-pack
> --supports-client-caps, ignore any output (which with current git will
> consist of a usage message), see if it returns a 0 exit code, if so,
> call git-upload-pack --client-caps='...', and if not just call
> git-upload-pack.  (A new git-upload-pack-2 binary would also work, but
> that seems like overkill.)  I don't see any way around the extra round
> trip here that would preserve backward compatibility with existing SSH
> servers (which may force clients to *only* run exactly the command
> "git-upload-pack" and nothing else).

Yep, that's about it. For ssh, I suspect we could optimistically try:

  git upload-pack --v2; test $? = 129 && git-upload-pack

and then fallback to just "git-upload-pack". That would work without an
extra round-trip on real shell-capable servers, and eventually work on
restricted ones.

That doesn't help git://, though.

There are proposals floating around for basically easing into it with
config. Have a "remote.*.v2" option you can set locally to enable (or
disable) it. Default to "false". When there are enough v2 servers around
to make it worthwhile, flip the default to "auto" which will do the
probing (at some minor expense of handling fallbacks). Optionally we
could record the last response for "auto" and use that going forward.

> Another possibility, which would work for both HTTPS and
> git-protocol-over-TLS, would be to use ALPN.

Do people actually use git-over-TLS? There's no core support AFAIK, so
you'd have to hack it up with a client proxy and git-remote-ext.

For HTTPS, I'd just as soon use HTTP-level features.


  reply	other threads:[~2016-08-16 20:54 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 [this message]
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

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

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