diff options
| author | Carlos Martín Nieto <cmn@elego.de> | 2013-11-23 17:07:55 +0100 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2013-11-25 13:16:19 -0800 |
| commit | 1ba98a79f1b991e6f2b1d01ac392ba2edadc3ca1 (patch) | |
| tree | 11c0b5f8bd0f9eb190bb4dca6682c2e53db52550 | |
| parent | f26f72de159d7ade2fbe8b48734ce98c1aba4d72 (diff) | |
| download | git-1ba98a79f1b991e6f2b1d01ac392ba2edadc3ca1.tar.gz | |
send-pack: don't send a thin pack to a server which doesn't support itcn/thin-push-capability
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>
| -rw-r--r-- | Documentation/technical/protocol-capabilities.txt | 31 | ||||
| -rw-r--r-- | send-pack.c | 2 |
2 files changed, 25 insertions, 8 deletions
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index fd8ffa5df3..e3e792476e 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -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 diff --git a/send-pack.c b/send-pack.c index fab62e3da0..9ee8cf50a8 100644 --- a/send-pack.c +++ b/send-pack.c @@ -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" |