On Sat, 8 Apr 2006, Johannes Schindelin wrote: > Hi, > > I just accidentally reran "git-repack -a -d" on a repository, where I just > had run it. And I noticed a funny thing: Of about 4000 objects, it reused > all but 8. So I reran it, and it reused all but 2. I ran it once again, > and it reused all. > > The really funny thing is: it created the same pack every time! Probably not. Subsequent packs were most probably even smaller ! > It is not critical, evidently, but I'd like to know what is causing this > rather undeterministic behaviour. (Before you ask: no, I did not make a > backup before running the tests, so I unfortunately cannot reproduce it). To reproduce, or rather to reset the pack state, just use "git-repack -a -f -d" then "git-repack -a -d" multiple times again. For example, on the current git archive: $ git-repack -a -f -d [...] Total 16548, written 16548 (delta 11007), reused 5390 (delta 0) Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created. pack size = 6032083 bytes. $ git-repack -a -d [...] Total 16548, written 16548 (delta 11030), reused 16525 (delta 11007) Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created. pack size = 5976610 bytes $ git-repack -a -d [...] Total 16548, written 16548 (delta 11030), reused 16548 (delta 11030) Pack pack-af9d39abfcb5fd6fd554f7fc8d1704f8dd2329e0 created. Pack size = 5976610 bytes So in this case it took 2 itterations before converging on a smaller pack by 55473 bytes. I thought the reuse logic might sacrifice a bit on compression given the speed boost, but I don't get why it is the opposite in practice and that -f doesn't produce the smallest pack up front. Nicolas - : 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