From: Jeff King <firstname.lastname@example.org> To: Josh Triplett <email@example.com> Cc: firstname.lastname@example.org Subject: Re: upload-pack/ls-remote: showing non-HEAD symbolic refs? Date: Tue, 16 Aug 2016 16:54:27 -0400 [thread overview] Message-ID: <email@example.com> (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: http://firstname.lastname@example.org/ 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. -Peff
next prev parent 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 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?' \ /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
Code repositories for project(s) associated with this 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).