Re: Funny repack behaviour

[Nicolas Pitre <nico@cam.org>]

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