| commit | 1bd8c8f00b1c7facb67c99047fe777b53f2c49ff | |
| author | Johannes Schindelin <Johannes.Schindelin@gmx.de> | |
| Fri, 28 Oct 2005 02:49:16 +0000 (28 04:49 +0200) | ||
| committer | Junio C Hamano <junkio@cox.net> | |
| Sat, 29 Oct 2005 05:57:00 +0000 (28 22:57 -0700) | ||
| tree | cadb874e52b57f53783babe827c05a99978e22fb | treesnapshot (tar.gz zip) |
| parent | 211b5f9e62cc961acda59392fbf5a3efa8106c97 | commitdiff |
git-upload-pack: Support the multi_ack protocol
This implements three things (trying very hard to be backwards
compatible):
It sends the "multi_ack" capability via the mechanism proposed by
Sergey Vlasov.
When the client sends "multi_ack" with at least one "want", multi_ack
is enabled.
When multi_ack is enabled, "continue" is appended to each "ACK" until
either the server can not store more refs, or "done" is received.
In contrast to the original protocol, as long as "continue" is sent,
flushes are answered by a "NAK" (not just until an "ACK" was sent),
and if "continue" was sent at least once, the last message is an
"ACK" without "continue".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements three things (trying very hard to be backwards
compatible):
It sends the "multi_ack" capability via the mechanism proposed by
Sergey Vlasov.
When the client sends "multi_ack" with at least one "want", multi_ack
is enabled.
When multi_ack is enabled, "continue" is appended to each "ACK" until
either the server can not store more refs, or "done" is received.
In contrast to the original protocol, as long as "continue" is sent,
flushes are answered by a "NAK" (not just until an "ACK" was sent),
and if "continue" was sent at least once, the last message is an
"ACK" without "continue".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
| upload-pack.c | diffblobblamehistory |