fix repack with --max-pack-size
commit5476a8adcc29985e5496dac7a340dfd178f43a17
authorNicolas Pitre <nico@cam.org>
Thu, 31 May 2007 01:43:12 +0000 (30 21:43 -0400)
committerJunio C Hamano <junkio@cox.net>
Thu, 31 May 2007 06:32:42 +0000 (30 23:32 -0700)
tree8f0a6c663b428f6a6e827e6b36c9ee3a8572e44b
parente3dfddb377478dbee9c5b88636e97d62312f562d
fix repack with --max-pack-size

Two issues here:

1) git-repack -a --max-pack-size=10 on the GIT repo dies pretty quick.
   There is a lot of confusion about deltas that were suposed to be
   reused from another pack but that get stored undeltified due to pack
   limit and object size doesn't match entry->size anymore.  This test
   is not really worth the complexity for determining when it is valid
   so get rid of it.

2) If pack limit is reached, the object buffer is freed, including when
   it comes from a cached delta data.  In practice the object will be
   stored in a subsequent pack undeltified, but let's make sure no
   pointer to freed data subsists by clearing entry->delta_data.

I also reorganized that code a bit to make it more readable.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-pack-objects.c