patchsend-pack: don't send a thin pack to a server which doesn't support it

> 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"

> 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"

> +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.