Re: 1.3.0 creating bigger packs than 1.2.3

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 20, 2006, 16:07 UTC
Message-ID: <Pine.LNX.4.64.0604200857460.3701@g5.osdl.org>
In-Reply-To: <20060420150315.GB31198@spearce.org>

On Thu, 20 Apr 2006, Shawn Pearce wrote:

Show 10 quoted lines

> 
> So with 1.3.0.g56c1 "git repack -a -d -f" did worse:
> 
>   Total 46391, written 46391 (delta 6649), reused 39742 (delta 0)
>   129M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack
> 
> I just tried -f on v1.2.3 and it did slightly better then before:
> 
>   Total 46391, written 46391 (delta 6847), reused 38012 (delta 0)
>    59M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack

Interesting. The bigger packs do generate fewer deltas, but they don't seem to be _that_ much fewer. And the deltas themselves certainly shouldn't be bigger.

It almost sounds like there's a problem with choosing what to delta against, not necessarily a delta algorithm problem. Although that sounds a bit strange, because I wouldn't have thought we actually changed the packing algorithm noticeably since 1.2.3.

Hmm. Doing "gitk v1.2.3.. -- pack-objects.c" shows that I was wrong. Junio did the "hash basename and direname a bit differently" thing, which would appear to change the "find objects to delta against" a lot. That could be it.

You could try to revert that change:

	git revert eeef7135fed9b8784627c4c96e125241c06c65e1

which needs a trivial manual fixup (remove the conflict entirely: everything between the "<<<<" and ">>>>>" lines should go), and see if that's it.

You can also try to see if

	git repack -a -d -f --window=50

makes for a better pack (at the cost of a much slower repack). It makes git try more objects to delta against, and can thus hide a bad sort order.

Junio, any other suggestions?

		Linus