git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Martín Nieto" <cmn@elego.de>
To: git@vger.kernel.org
Cc: jrnieder@gmail.com, pclouds@gmail.com
Subject: [PATCH 1/2] receive-pack: advertise thin-pack
Date: Wed,  6 Nov 2013 16:04:22 +0100	[thread overview]
Message-ID: <1383750263-32495-2-git-send-email-cmn@elego.de> (raw)
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

  reply	other threads:[~2013-11-06 15:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 15:04 [PATCH 0/2] thin-pack capability for send-pack/receive-pack Carlos Martín Nieto
2013-11-06 15:04 ` Carlos Martín Nieto [this message]
2013-11-06 15:04 ` [PATCH 2/2] send-pack: only send a thin pack if the server supports it Carlos Martín Nieto
2013-11-06 20:32 ` [PATCH 0/2] thin-pack capability for send-pack/receive-pack Junio C Hamano
2013-11-06 21:41   ` Carlos Martín Nieto
2013-11-06 22:25     ` Junio C Hamano
2013-11-06 22:54       ` Jeff King
2013-11-06 23:47         ` Shawn Pearce
2013-11-06 23:42     ` Shawn Pearce
2013-11-23 15:09       ` Carlos Martín Nieto

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=1383750263-32495-2-git-send-email-cmn@elego.de \
    --to=cmn@elego.de \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    /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).