On Tue, 2 Jan 2018 16:18:02 -0800 Brandon Williams <bmwill@xxxxxxxxxx> wrote: > The following patches extend what I sent out as an WIP > (https://public-inbox.org/git/20171204235823.63299-1-bmwill@xxxxxxxxxx/) 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@xxxxxxxxxx/ > 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.
