Re: thin packs ending up fat

From: Jeff King <peff@peff.net>
Date: Jan 13, 2012, 01:51 UTC
Message-ID: <20120113015117.GA8245@sigill.intra.peff.net>
In-Reply-To: <7vwr8wz8u9.fsf@alter.siamese.dyndns.org>

On Thu, Jan 12, 2012 at 05:31:42PM -0800, Junio C Hamano wrote:

> From: Jeff King <peff@peff.net>
> Subject: [PATCH] thin-pack: try harder to create delta against preferred base

I just sat down to write a nicer commit message, and behold, it was done for me. Thanks.

Show 8 quoted lines

> When creating a thin-pack to transfer recent history, it is likely that we
> will try to send an object that is recorded in full, as it is newer.  But
> the heuristics to avoid recomputing futile delta effectively forbids us
> from attempting to express such an object as a delta based on another
> object. Sending an object in full is often more expensive than sending a
> suboptimal delta based on other objects, and it is even more so if we
> could use an object we know the receiving end already has (i.e. referred
> base object) as the delta base.

s/referred/preferred/

> Tweak the recomputation avoidance logic, so that we do not punt on
> computing delta against a preferred base object.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Other than that, it looks good to me.

Signed-off-by: Jeff King <peff@peff.net>

I'll try to deploy this to GitHub in the near future. I doubt we'll see much of a dent in our bandwidth, though, as small fetches that this helps are probably lost in the noise of clones.

-Peff