Re: Is anyone working on a next-gen Git protocol?

[Jeff King <peff@peff.net>]

On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote:

> Has anyone started working on a next-gen Git protocol as a result of
> this discussion? If not I thought I'd give it a shot if/when I have
> time.

I haven't, and don't really plan on it soon (I have a few smaller things
I'm working on, then I'd like to look into the EWAH bitmap stuff from
Shawn next).

> The current protocol is basically (S = Server, C = Client)
> 
>  S: Spew out first ref
>  S: Advertisement of capabilities
>  S: Dump of all our refs
>  C/S: Declare wanted refs, negotiate with server
>  S: Send pack to client, if needed

In the "C" portion there, there is also "client acknowledges a
subset of capabilities shown by server" while it is declaring wanted
refs.

> And I thought I'd basically turn it into:
> 
>  C: Connect to server, declare what protocol we understand
>  C: Advertisement of capabilities
>  S: Advertisement of capabilities

The capability negotiation right now is that the server offers and the
client accepts. Are you swapping that so that the client offers and the
server accepts? Or are you thinking that they would be sent
simultaneously here? That could drop one round-trip (it's probably not
that important for git-over-tcp, but smart-http cares a lot about round
trips). But it also introduces a complexity with future additions (one
side may not know how to present its capabilities until understanding
what the other side can do).

>  C/S: Negotiate what we want

Refs we want, or capabilities we want?

>  C/S: Same as v1, without the advertisement of capabilities, and maybe
> don't dump refs at all
> 
> Basically future-proofing it by having the client say what it supports
> to begin with along with what it can handle (like in HTTP).

I feel like this "maybe..." bit needs more fleshed out before designing
the first part. I like the idea of future-proofing first and then adding
new features second, but what does the "don't advertise all refs"
protocol look like? Presumably the client is going to say "I'm
interested in refs/heads/* and refs/tags/*" or something. Does that come
with the capabilities? Or is it a new protocol phase?

I think we need to know what the second half of the two-step process
will look like to be sure the first half will accommodate it (and the
answer may be as simple as saying "they're not sending capabilities,
they're sending arbitrary key/value items, with the knowledge that the
other side may not understand particular keys, and we have to be
prepared to handle both cases).

> Then in the negotiation phase the client & server would go back &
> forth about what they want & how they want it. I'd planned to
> implement something like:
> 
>     C: want_refs refs/heads/*
>     S: OK to that
>     C: want_refs refs/tags/*
>     S: OK to that
> 
> Or:
> 
>     C: want_refs refs/heads/master
>     S: OK to that
>     C: want_refs refs/tags/v*
>     S: OK to that

That seems simple. But how will it work over smart-http? Are we adding a
round-trip to do want_refs negotiation?

-Peff