send-pack: don't send a thin pack to a server which doesn't support it
authorCarlos Martín Nieto <cmn@elego.de>
Sat, 23 Nov 2013 16:07:55 +0000 (17:07 +0100)
committerJunio C Hamano <gitster@pobox.com>
Mon, 25 Nov 2013 21:16:19 +0000 (13:16 -0800)
Up to now git has assumed that all servers are able to fix thin
packs. This is however not always the case.

Document the 'no-thin' capability and prevent send-pack from generating
a thin pack if the server advertises it.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/technical/protocol-capabilities.txt
send-pack.c

index fd8ffa5df38c8dd1a682ab77327654a4c2b80cd4..e3e792476e7a6b7554582469b2c5ac172b2f17dd 100644 (file)
@@ -72,14 +72,29 @@ interleaved with S-R-Q.
 thin-pack
 ---------
 
-This capability means that the server can send a 'thin' pack, a pack
-which does not contain base objects; if those base objects are available
-on client side. Client requests 'thin-pack' capability when it
-understands how to "thicken" it by adding required delta bases making
-it self-contained.
-
-Client MUST NOT request 'thin-pack' capability if it cannot turn a thin
-pack into a self-contained pack.
+A thin pack is one with deltas which reference base objects not
+contained within the pack (but are known to exist at the receiving
+end). This can reduce the network traffic significantly, but it
+requires the receiving end to know how to "thicken" these packs by
+adding the missing bases to the pack.
+
+The upload-pack server advertises 'thin-pack' when it can generate
+and send a thin pack. A client requests the 'thin-pack' capability
+when it understands how to "thicken" it, notifying the server that
+it can receive such a pack. A client MUST NOT request the
+'thin-pack' capability if it cannot turn a thin pack into a
+self-contained pack.
+
+Receive-pack, on the other hand, is assumed by default to be able to
+handle thin packs, but can ask the client not to use the feature by
+advertising the 'no-thin' capability. A client MUST NOT send a thin
+pack if the server advertises the 'no-thin' capability.
+
+The reasons for this asymmetry are historical. The receive-pack
+program did not exist until after the invention of thin packs, so
+historically the reference implementation of receive-pack always
+understood thin packs. Adding 'no-thin' later allowed receive-pack
+to disable the feature in a backwards-compatible manner.
 
 
 side-band, side-band-64k
index fab62e3da05913b5a4f76db7ed1c17e5831384d2..9ee8cf50a830ed85f134825dcf1d41287a21f046 100644 (file)
@@ -206,6 +206,8 @@ int send_pack(struct send_pack_args *args,
                quiet_supported = 1;
        if (server_supports("agent"))
                agent_supported = 1;
+       if (server_supports("no-thin"))
+               args->use_thin_pack = 0;
 
        if (!remote_refs) {
                fprintf(stderr, "No refs in common and none specified; doing nothing.\n"