Is anyone working on a next-gen Git protocol?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I'm creating a system where a lot of remotes constantly fetch from a
>> central repository for deployment purposes, but I've noticed that even
>> with a remote.$name.fetch configuration to only get certain refs a
>> "git fetch" will still call git-upload pack which will provide a list
>> of all references.
>
> It has been observed that the sender has to advertise megabytes of
> refs because it has to speak first before knowing what the receiver
> wants, even when the receiver is interested in getting updates from
> only one of them, or worse yet, when the receiver is only trying to
> peek the ref it is interested has been updated.

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.

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

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
 C/S: Negotiate what 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).

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

As a proof of concept (and also something that'll solve the issue I
had), but by adding an initial negotiation phase the protocol should
be open to any future extensions without making assumptions about the
client wanting to know about all of the server's refs, unlike the
current protocol.