From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 93EED1F406 for ; Tue, 9 Jan 2018 17:55:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934610AbeAIRzl (ORCPT ); Tue, 9 Jan 2018 12:55:41 -0500 Received: from mail-pg0-f46.google.com ([74.125.83.46]:44423 "EHLO mail-pg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934606AbeAIRzh (ORCPT ); Tue, 9 Jan 2018 12:55:37 -0500 Received: by mail-pg0-f46.google.com with SMTP id i5so8477545pgq.11 for ; Tue, 09 Jan 2018 09:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=g4wfyI0JKAzD3gCe14N7sgMYr+US2mbZj9varmY1ELg=; b=DGFltsKLaWwRbST/N6eLxLdJvuE4eML0tzOrEyvP1iHMvYTyNeaPa6GTUp1wBTy9UM Fgvs2Bt4gjSfy6/03Os5irdZzc3KIsxwiG3Y+tzrN6qhRYimm6keox2wx/uJc0LvnKSy mOaWK+vHcteKIJ7dsv/RTZZ2cW1r9Y7qcFXs8JATah1zOoZ96hZZecWmEAlSYflB+Ec1 SCeyROy5MPIpLJrseWvr/GoLPl+uND7GBrJg+mZv1or4AC6S2I/2xQ8ORCv3OqQK1+yF 3/n2IpXiUFWew0pW6IAzUM7/PyGtzix4oH+4ZXa2Rgktf7+qdIRX+M9auwIVQUiQ0ocf jo1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=g4wfyI0JKAzD3gCe14N7sgMYr+US2mbZj9varmY1ELg=; b=dG1qDMvZwSwmYHhkYEl5iDxSfVyV35m0P1V4Pi7saD1meyzpeGFz6LfvjXSxOS/lw6 xrwipIVn7asAsh522kVBFPfofRgBC7GSBU4VUM0O4ksnuzINPyf7k3ZDQQd6G0QaGi3u gf1xdBE9AEF5jFYpwdniFU/EgoTO7+mDyOq4UuJ4yUTIYJ6uHH0WgH6hjJEBf9mP92mD nXdPH+QkejiK4U4iEGS9s7gDVNaPv5SfCZPilNEU9lGCguBljszFUQpXb04cwWk8K1KZ SnmXQYH+gCqWNfhIGPAeaHxwFY58+KJBncBsStw7lbgn+j0nTbZN1NGYHJcxcATAYJtD j7jg== X-Gm-Message-State: AKGB3mJpqeJKeJI2ag+xNjangx0X1dNbSnrMj6JQaovuwydixVV0JnNn 7VUS463XYZmEdh/MUheYno2P/EYzucQ= X-Google-Smtp-Source: ACJfBovje1fOF7P1N6OKp7HeGik2wX8jeMP2GWUZhr18LdnCEEK14eQDJZLg//6ft61Lm+/3hwIcQg== X-Received: by 10.98.254.11 with SMTP id z11mr6025701pfh.48.1515520536613; Tue, 09 Jan 2018 09:55:36 -0800 (PST) Received: from twelve3.mtv.corp.google.com ([2620:0:100e:422:592e:240e:24e2:56aa]) by smtp.gmail.com with ESMTPSA id h13sm28611816pfi.40.2018.01.09.09.55.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 09:55:35 -0800 (PST) Date: Tue, 9 Jan 2018 09:55:34 -0800 From: Jonathan Tan To: Brandon Williams Cc: git@vger.kernel.org, sbeller@google.com, gitster@pobox.com, peff@peff.net, philipoakley@iee.org, stolee@gmail.com, jrnieder@gmail.com Subject: Re: [PATCH 00/26] protocol version 2 Message-Id: <20180109095534.c0c9b9ad3933d406c993c3ab@google.com> In-Reply-To: <20180103001828.205012-1-bmwill@google.com> References: <20180103001828.205012-1-bmwill@google.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, 2 Jan 2018 16:18:02 -0800 Brandon Williams wrote: > The following patches extend what I sent out as an WIP > (https://public-inbox.org/git/20171204235823.63299-1-bmwill@google.com/) and > implement protocol version 2. Summarizing (for myself) the rationale for protocol version 2: The existing protocol has a few pain points: (a) limit on the length of the capability line (the capability line can be used to include additional parameters in a backwards-compatible way), (b) difficulty in creating proxies because of inconsistent flush semantics, and (c) the need to implement clients twice - once for HTTP and once for connect-supporting transports. To which we can add another: (d) if we want to support something entirely new (for example, a server-side "git log"), we will need a new protocol anyway. The new functionality introduced in this patch set is probably best done using a new protocol. If it were done using the existing protocol (by adding a parameter in the capabilities line), we would still run into (a) and (c), so we might as well introduce the new protocol now. Some of the above points are repeats from my previous e-mail: https://public-inbox.org/git/20171110121347.1f7c184c543622b60164e9fb@google.com/ > Some changes from that series are as follows: > * Lots of various cleanup on the ls-refs and fetch command code, both server > and client. > * Fetch command now supports a stateless-rpc mode which enables communicating > with a half-duplex connection. Good to hear about fetch support. > * Introduce a new remote-helper command 'connect-half-duplex' which is > implemented by remote-curl (the http remote-helper). This allows for a > client to establish a half-duplex connection and use remote-curl as a proxy > to wrap requests in http before sending them to the remote end and > unwrapping the responses and sending them back to the client's stdin. I'm not sure about the "half-duplex" name - it is half-duplex in that each side must terminate their communications with a flush, but not half-duplex in that request-response pairs can overlap each other (e.g. during negotation during fetch - there is an optimization in which the client tries to keep two requests pending at a time). I think that the idea we want to communicate is that requests and responses are always packetized, stateless, and always happen as a pair. I wonder if "stateless-connect" is a better keyword - it makes sense to me (once described) that "stateless" implies that the client sends everything the server needs at once (thus, in a packet), the server sends everything the client needs back at once (thus, in a packet), and then the client must not assume any state-storing on the part of the server or transport. > * The transport code is refactored for ls-remote, fetch, and push to provide a > list of ref-patterns (based on the refspec being used) when requesting refs > from the remote end. This allows the ls-refs code to send this list of > patterns so the remote end and filter the refs it sends back. Briefly looking at the implementation, the client seems to incur an extra roundtrip when using ls-remote (and others) with a v2-supporting server. I initially didn't like this, but upon further reflection, this is probably fine for now. The client can be upgraded later, and I think that clients will eventually want to query git-serve directly for "ls-refs" first, and then fall back to v0 for ancient servers, instead of checking git-upload-pack first (as in this patch set) - so, the support for "ls-refs" here won't be carried forward merely for backwards compatibility, but will eventually be actively used. As for the decision to use a new endpoint "git-serve" instead of reusing "git-upload-pack" (or "git-receive-pack"), reusing the existing one might allow some sort of optimization later in which the first "git-upload-pack" query immediately returns with the v2 answer (instead of redirecting the client to "git-serve"), but this probably doesn't matter in practice (as I stated above, I think that eventually clients will query git-serve first). > This series effectively implements protocol version 2 for listing a remotes > refs (ls-remote) as well as for fetch for the builtin transports (ssh, git, > file) and for the http/https transports. Push is not implemented yet and > doesn't need to be implemented at the same time as fetch since the > receive-pack code can default to using protocol v0 when v2 is requested by the > client. Agreed - push can be done later.