git-upload-pack: Support sending multiple ACK messages

The current fetch/upload protocol works like this:

- client sends revs it wants to have via "want" messages
- client sends a flush message (message with len 0)
- client sends revs it has via "have" messages
- after one window (32 revs), a flush is sent
- after each subsequent window, a flush is sent, and an ACK/NAK is received.
        (NAK means that server does not have any of the transmitted revs;
         ACK sends also the sha1 of the rev server has)
 - when the first ACK is received, client sends "done", and does not expect
        any further messages

One special case, though:

- if no ACK is received (only NAK's), and client runs out of revs to send,
        "done" is sent, and server sends just one more "NAK"

A smarter scheme, which actually has a chance to detect more than one
common rev, would be to send more than just one ACK. This patch implements
the server side of the following extension to the protocol:

- client sends at least one "want" message with "multi_ack" appended, like

        "want 1234567890123456789012345678901234567890 multi_ack"

- if the server understands that extension, it will send ACK messages for all
        revs it has, not just the first one

- server appends "continue" to the ACK messages like

        "ACK 1234567890123456789012345678901234567890 continue"

        until it has MAX_HAS-1 revs. In this manner, client knows when to
        stop sending revs by checking for the substring "continue" (and
        further knows that server understands multi_ack)

In this manner, the protocol stays backwards compatible, since both client
must send "want ... multi_ack" and server must answer with "ACK ...
continue" to enable the extension.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

0 files changed, 0 insertions, 0 deletions