[PATCH 1/2] receive-pack: advertise thin-pack
- From
Carlos Martín Nieto <cmn@elego.de>
- Date
- Nov 6, 2013, 15:04 UTC
- Message-ID
- <1383750263-32495-2-git-send-email-cmn@elego.de>
- In-Reply-To
- <1383750263-32495-1-git-send-email-cmn@elego.de>
upload-pack has long advertised thin-pack, letting the clients request these smaller packs. The client however unconditionally assumes that a server is able to fix thin packs and there is no way of telling the client that this is in fact not the case.
Make receive-pack advertise 'thin-pack' in anticipation of the client toggling the assumption and document this capability when used by receive-pack.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> --- Documentation/technical/protocol-capabilities.txt | 20 +++++++++++++++----- builtin/receive-pack.c | 2 +- 2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index fd8ffa5..4e96d51 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -72,15 +72,25 @@ 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. +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. The receive-pack server advertises 'thin-pack' when +it knows how to "thicken" the pack it receives. + +Likewise, the client requests the 'thin-pack' capability when it +understands how to "thicken" it. Client MUST NOT request 'thin-pack' capability if it cannot turn a thin pack into a self-contained pack. +Client MUST NOT send a thin pack if the server does not advertise this +capability. + side-band, side-band-64k ------------------------ diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index e3eb5fc..0e35c02 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -132,7 +132,7 @@ static void show_ref(const char *path, const unsigned char *sha1) else packet_write(1, "%s %s%c%s%s agent=%s\n", sha1_to_hex(sha1), path, 0, - " report-status delete-refs side-band-64k quiet", + " report-status delete-refs side-band-64k quiet thin-pack", prefer_ofs_delta ? " ofs-delta" : "", git_user_agent_sanitized()); sent_capabilities = 1;
-- 1.8.4.652.g0d6e0ce