From: "Carlos Martín Nieto" <cmn@elego.de>
To: git@vger.kernel.org
Cc: gitster@pobox.com, jrnieder@gmail.com, pclouds@gmail.com,
spearce@spearce.org, peff@peff.net
Subject: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it
Date: Sat, 23 Nov 2013 17:07:55 +0100 [thread overview]
Message-ID: <1385222875-13369-1-git-send-email-cmn@elego.de> (raw)
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.
---
This is a re-roll of the series I sent earlier this month, switching
it around by adding the "no-thin"
Documentation/technical/protocol-capabilities.txt | 20 +++++++++++++++-----
send-pack.c | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index fd8ffa5..3a75e79 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 'no-thin' if
+it does not know how to "thicken" the pack it receives.
+
+A 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 advertises the
+'no-thin' capability.
+
side-band, side-band-64k
------------------------
diff --git a/send-pack.c b/send-pack.c
index 7d172ef..9877eb9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -205,6 +205,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"
--
1.8.5.rc3.362.gdf10213
next reply other threads:[~2013-11-23 16:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-23 16:07 Carlos Martín Nieto [this message]
2013-11-23 16:17 ` [PATCH] send-pack: don't send a thin pack to a server which doesn't support it Carlos Martín Nieto
2013-11-24 6:07 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1385222875-13369-1-git-send-email-cmn@elego.de \
--to=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).