{"thread":{"id":"35396","subject":"[PATCH] send-pack: don't send a thin pack to a server which doesn't support it","startedAt":"2013-11-23T16:07:55Z","lastAt":"2013-11-24T06:07:46Z","messageCount":3,"participants":["Carlos Martín Nieto","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"230994","messageId":"1385222875-13369-1-git-send-email-cmn@elego.de","threadId":"35396","inReplyTo":null,"subject":"[PATCH] send-pack: don't send a thin pack to a server which doesn't support it","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2013-11-23T16:07:55Z","receivedAt":"2013-11-23T16:07:55Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"Up to now git has assumed that all servers are able to fix thin\npacks. This is however not always the case.\n\nDocument the 'no-thin' capability and prevent send-pack from generating\na thin pack if the server advertises it.\n---\n\nThis is a re-roll of the series I sent earlier this month, switching\nit around by adding the \"no-thin\" \n\n Documentation/technical/protocol-capabilities.txt | 20 +++++++++++++++-----\n send-pack.c                                       |  2 ++\n 2 files changed, 17 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt\nindex fd8ffa5..3a75e79 100644\n--- a/Documentation/technical/protocol-capabilities.txt\n+++ b/Documentation/technical/protocol-capabilities.txt\n@@ -72,15 +72,25 @@ interleaved with S-R-Q.\n thin-pack\n ---------\n \n-This capability means that the server can send a 'thin' pack, a pack\n-which does not contain base objects; if those base objects are available\n-on client side. Client requests 'thin-pack' capability when it\n-understands how to \"thicken\" it by adding required delta bases making\n-it self-contained.\n+A thin pack is one with deltas which reference base objects not\n+contained within the pack (but are known to exist at the receiving\n+end). This can reduce the network traffic significantly, but it\n+requires the receiving end to know how to \"thicken\" these packs by\n+adding the missing bases to the pack.\n+\n+The upload-pack server advertises 'thin-pack' when it can generate and\n+send a thin pack. The receive-pack server advertises 'no-thin' if\n+it does not know how to \"thicken\" the pack it receives.\n+\n+A client requests the 'thin-pack' capability when it understands how\n+to \"thicken\" it.\n \n Client MUST NOT request 'thin-pack' capability if it cannot turn a thin\n pack into a self-contained pack.\n \n+Client MUST NOT send a thin pack if the server advertises the\n+'no-thin' capability.\n+\n \n side-band, side-band-64k\n ------------------------\ndiff --git a/send-pack.c b/send-pack.c\nindex 7d172ef..9877eb9 100644\n--- a/send-pack.c\n+++ b/send-pack.c\n@@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,\n \t\tquiet_supported = 1;\n \tif (server_supports(\"agent\"))\n \t\tagent_supported = 1;\n+\tif (server_supports(\"no-thin\"))\n+\t\targs->use_thin_pack = 0;\n \n \tif (!remote_refs) {\n \t\tfprintf(stderr, \"No refs in common and none specified; doing nothing.\\n\"\n-- \n1.8.5.rc3.362.gdf10213\n"},{"id":"230995","messageId":"1385223449.2665.21.camel@centaur.cmartin.tk","threadId":"35396","inReplyTo":"1385222875-13369-1-git-send-email-cmn@elego.de","subject":"Re: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2013-11-23T16:17:29Z","receivedAt":"2013-11-23T16:17:29Z","isPatch":true,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Sat, 2013-11-23 at 17:07 +0100, Carlos Martín Nieto wrote:\n> Up to now git has assumed that all servers are able to fix thin\n> packs. This is however not always the case.\n> \n> Document the 'no-thin' capability and prevent send-pack from generating\n> a thin pack if the server advertises it.\n\nSorry,\n\nSigned-off-by: Carlos Martín Nieto <cmn@elego.de>\n\n> ---\n> \n> This is a re-roll of the series I sent earlier this month, switching\n> it around by adding the \"no-thin\" \n> \n>  Documentation/technical/protocol-capabilities.txt | 20 +++++++++++++++-----\n>  send-pack.c                                       |  2 ++\n>  2 files changed, 17 insertions(+), 5 deletions(-)\n> \n> diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt\n> index fd8ffa5..3a75e79 100644\n> --- a/Documentation/technical/protocol-capabilities.txt\n> +++ b/Documentation/technical/protocol-capabilities.txt\n> @@ -72,15 +72,25 @@ interleaved with S-R-Q.\n>  thin-pack\n>  ---------\n>  \n> -This capability means that the server can send a 'thin' pack, a pack\n> -which does not contain base objects; if those base objects are available\n> -on client side. Client requests 'thin-pack' capability when it\n> -understands how to \"thicken\" it by adding required delta bases making\n> -it self-contained.\n> +A thin pack is one with deltas which reference base objects not\n> +contained within the pack (but are known to exist at the receiving\n> +end). This can reduce the network traffic significantly, but it\n> +requires the receiving end to know how to \"thicken\" these packs by\n> +adding the missing bases to the pack.\n> +\n> +The upload-pack server advertises 'thin-pack' when it can generate and\n> +send a thin pack. The receive-pack server advertises 'no-thin' if\n> +it does not know how to \"thicken\" the pack it receives.\n> +\n> +A client requests the 'thin-pack' capability when it understands how\n> +to \"thicken\" it.\n>  \n>  Client MUST NOT request 'thin-pack' capability if it cannot turn a thin\n>  pack into a self-contained pack.\n>  \n> +Client MUST NOT send a thin pack if the server advertises the\n> +'no-thin' capability.\n> +\n>  \n>  side-band, side-band-64k\n>  ------------------------\n> diff --git a/send-pack.c b/send-pack.c\n> index 7d172ef..9877eb9 100644\n> --- a/send-pack.c\n> +++ b/send-pack.c\n> @@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,\n>  \t\tquiet_supported = 1;\n>  \tif (server_supports(\"agent\"))\n>  \t\tagent_supported = 1;\n> +\tif (server_supports(\"no-thin\"))\n> +\t\targs->use_thin_pack = 0;\n>  \n>  \tif (!remote_refs) {\n>  \t\tfprintf(stderr, \"No refs in common and none specified; doing nothing.\\n\"\n"},{"id":"231006","messageId":"20131124060745.GA5289@sigill.intra.peff.net","threadId":"35396","inReplyTo":"1385222875-13369-1-git-send-email-cmn@elego.de","subject":"Re: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-24T06:07:46Z","receivedAt":"2013-11-24T06:07:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 23, 2013 at 05:07:55PM +0100, Carlos Martín Nieto wrote:\n\n> Up to now git has assumed that all servers are able to fix thin\n> packs. This is however not always the case.\n> \n> Document the 'no-thin' capability and prevent send-pack from generating\n> a thin pack if the server advertises it.\n> ---\n> \n> This is a re-roll of the series I sent earlier this month, switching\n> it around by adding the \"no-thin\"\n\nThanks, I think this moves in the right direction.\n\nI wonder if we want to call it \"no-thin-pack\" just for consistency with\nthe affirmative version in upload-pack.\n\n> +The upload-pack server advertises 'thin-pack' when it can generate and\n> +send a thin pack. The receive-pack server advertises 'no-thin' if\n> +it does not know how to \"thicken\" the pack it receives.\n> +\n> +A client requests the 'thin-pack' capability when it understands how\n> +to \"thicken\" it.\n>  \n>  Client MUST NOT request 'thin-pack' capability if it cannot turn a thin\n>  pack into a self-contained pack.\n>  \n> +Client MUST NOT send a thin pack if the server advertises the\n> +'no-thin' capability.\n\nAs somebody who participated in the discussion, I know why one is in the\naffirmative and one is in the negative. But I think it might help a\nreader of the spec to emphasize the difference, and to put the client\nbehavior for each alongside the server behavior, like:\n\n  The upload-pack server advertises 'thin-pack' when it can generate and\n  send a thin pack. A client requests the 'thin-pack' capability when it\n  understands how to \"thicken\" it, notifying the server that it can\n  receive such a pack. A client MUST NOT request the 'thin-pack'\n  capability if it cannot turn a thin pack into a self-contained pack.\n\n  Receive-pack, on the other hand, is assumed by default to be able to\n  handle thin packs, but can ask the client not to use the feature by\n  advertising the 'no-thin' capability. A client MUST NOT send a thin\n  pack if the server advertises the 'no-thin' capability.\n\n  The reasons for this asymmetry are historical. The receive-pack\n  program did not exist until after the invention of thin packs, so\n  historically the reference implementation of receive-pack always\n  understood thin packs. Adding 'no-thin' later allowed receive-pack to\n  disable the feature in a backwards-compatible manner.\n\n-Peff\n"}]}