mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

send-pack: don't send a thin pack to a server which doesn't support it

Browse Source 
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>
This commit is contained in:
Carlos Martín Nieto
2013-11-23 17:07:55 +01:00
committed by Junio C Hamano
parent f26f72de15
commit 1ba98a79f1
2 changed files with 24 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
Documentation/technical/protocol-capabilities.txt
View File

@ -72,14 +72,29 @@ interleaved with S-R-Q.
thin-pack thin-pack
--------- ---------
This capability means that the server can send a 'thin' pack, a pack A thin pack is one with deltas which reference base objects not
which does not contain base objects; if those base objects are available contained within the pack (but are known to exist at the receiving
on client side. Client requests 'thin-pack' capability when it end). This can reduce the network traffic significantly, but it
understands how to "thicken" it by adding required delta bases making requires the receiving end to know how to "thicken" these packs by
it self-contained. adding the missing bases to the pack.
Client MUST NOT request 'thin-pack' capability if it cannot turn a thin The upload-pack server advertises 'thin-pack' when it can generate
pack into a self-contained pack. 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 side-band, side-band-64k

2
send-pack.c
View File

@ -206,6 +206,8 @@ int send_pack(struct send_pack_args *args,
quiet_supported = 1; quiet_supported = 1;
if (server_supports("agent")) if (server_supports("agent"))
agent_supported = 1; agent_supported = 1;
if (server_supports("no-thin"))
args->use_thin_pack = 0;
if (!remote_refs) { if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n" fprintf(stderr, "No refs in common and none specified; doing nothing.\n"