Funny repack behaviour

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!

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).

Ciao, Dscho

P.S.: This is the output:

$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
 100% (4259/4259) done
Writing 4259 objects.
 100% (4259/4259) done
Total 4259, written 4259 (delta 3391), reused 4241 (delta 3379)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
 100% (4259/4259) done
Writing 4259 objects.
 100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4257 (delta 3391)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.
$ git-repack -a -d
Generating pack...
Done counting 4259 objects.
Deltifying 4259 objects.
 100% (4259/4259) done
Writing 4259 objects.
 100% (4259/4259) done
Total 4259, written 4259 (delta 3393), reused 4259 (delta 3393)
Pack pack-66bd976bbdc2ac6da623b8af02037218ecd72ef0 created.

On Sat, 8 Apr 2006, Johannes Schindelin wrote:

Probably not.  Subsequent packs were most probably even smaller !

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

Hi,

On Sat, 8 Apr 2006, Nicolas Pitre wrote:

Oh, you're right. I was tricked by the identical pack-names. Somehow I forgot that the pack name just reflects a hash of the _unpacked_ objects, not the pack file itself.

Sorry for the noise.

Ciao, Dscho