On Thu, 20 Apr 2006, Shawn Pearce wrote: > > 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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html