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

From: Jeff King <peff@peff.net>
Date: Nov 24, 2013, 06:07 UTC
Message-ID: <20131124060745.GA5289@sigill.intra.peff.net>
In-Reply-To: <1385222875-13369-1-git-send-email-cmn@elego.de>

On Sat, Nov 23, 2013 at 05:07:55PM +0100, Carlos Martín Nieto wrote:

Show 9 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.
> ---
> 
> This is a re-roll of the series I sent earlier this month, switching
> it around by adding the "no-thin"

Thanks, I think this moves in the right direction.

I wonder if we want to call it "no-thin-pack" just for consistency with the affirmative version in upload-pack.

Show 12 quoted lines

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

As somebody who participated in the discussion, I know why one is in the affirmative and one is in the negative. But I think it might help a reader of the spec to emphasize the difference, and to put the client behavior for each alongside the server behavior, like:

  The upload-pack server advertises 'thin-pack' when it can generate and
  send a thin pack. A client requests the 'thin-pack' capability when it
  understands how to "thicken" it, notifying the server that it can
  receive such a pack. A client MUST NOT request the 'thin-pack'
  capability if it cannot turn a thin pack into a self-contained pack.

  Receive-pack, on the other hand, is assumed by default to be able to
  handle thin packs, but can ask the client not to use the feature by
  advertising the 'no-thin' capability. A client MUST NOT send a thin
  pack if the server advertises the 'no-thin' capability.

  The reasons for this asymmetry are historical. The receive-pack
  program did not exist until after the invention of thin packs, so
  historically the reference implementation of receive-pack always
  understood thin packs. Adding 'no-thin' later allowed receive-pack to
  disable the feature in a backwards-compatible manner.

-Peff