Re: [PATCH/RFC] reverse the pack-objects delta window logic

From: Nicolas Pitre <nico@cam.org>
Date: Apr 26, 2006, 17:48 UTC
Message-ID: <Pine.LNX.4.64.0604261341200.18520@localhost.localdomain>
In-Reply-To: <7vpsj4sxer.fsf@assigned-by-dhcp.cox.net>

On Tue, 25 Apr 2006, Junio C Hamano wrote:

Show 11 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> > Note, this is a RFC particularly to Junio since the resulting pack is 
> > larger than without the patch with git-repack -a -f.  However using a 
> > subsequent git-repack -a brings the pack size down to expected size.  So 
> > I'm not sure I've got everything right.
> 
> I haven't tested it seriously yet, but there is nothing that
> looks obviously wrong that might cause the inflation problem,
> from the cursory look after applying the patch on top of your
> last round.

Never mind. I found a flaw in the determination of delta_limit when reparenting a delta target. The immediate parent's delta_limit is readjusted when its longest delta is moved to another base, but if that parent was itself a delta then the delta_limit adjustment is not propagated back up to the top. This means that some objects were falsely credited with too high delta_limit.

And actually I'm not sure how to solve that without walking the tree up to the top each time, which I want to avoid as much as possible.

Nicolas