Re: Funny repack behaviour

From: Nicolas Pitre <nico@cam.org>
Date: Apr 8, 2006, 19:44 UTC
Message-ID: <Pine.LNX.4.64.0604081528070.2215@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.63.0604081233170.3283@wbgn013.biozentrum.uni-wuerzburg.de>

On Sat, 8 Apr 2006, Johannes Schindelin wrote:

Show 8 quoted lines

> 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