git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] send-pack: don't send a thin pack to a server which doesn't support it

From
Carlos Martín Nieto <cmn@elego.de>
Date
Nov 23, 2013, 16:17 UTC
Message-ID
<1385223449.2665.21.camel@centaur.cmartin.tk>
In-Reply-To
<1385222875-13369-1-git-send-email-cmn@elego.de>
On Sat, 2013-11-23 at 17:07 +0100, Carlos Martín Nieto wrote:
Show 5 quoted lines
> 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.
Sorry,
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Show 57 quoted lines
> ---
> 
> 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"
Previous: Carlos Martín NietoNext: Jeff King
Message 2 of 3 in “send-pack: don't send a thin pack to a server which doesn't support it”
  1. send-pack: don't send a thin pack to a server which doesn't support itCarlos Martín Nieto, Nov 23, 2013
  2. Carlos Martín NietoNov 23, 2013
  3. Jeff KingNov 24, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.