I just tried the patch below on a couple-month-old Linux 2.6 repository from Linus (last commit: Feb 14 2006). It did not decrease the pack file size by much despite the higher delta: 'next' Total 189435, written 189435 (delta 142093), reused 44057 (delta 0) 'next'+patch Total 189435, written 189435 (delta 142712), reused 43954 (delta 0) 'next' 104464297 bytes 'next'+patch 104092920 bytes (99.6% of 'next') 'next' 328.98 real 206.02 user 93.60 sys 'next'+patch 363.06 real 218.98 user 94.72 sys So it looks like the patch is taking longer to run, and by about 10%. An expensive price to pay for what amounts to only a 0.4% reduction in pack size on the kernel. Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > Based on Linus' comment I changed your patch to just the following. > It still produced the 46M pack file, so the first hunk apears to > not have had much of an affect with this data. > > From a running time perspective it appears as though this patch is > making things slightly better, not worse. I ran it a few times > for each case always using the 46M pack as input for > "git-repack -a -d -f". > > 'next' 137.13 real 95.82 user 25.24 sys > 'next'+patch 131.62 real 89.35 user 28.56 sys > > but even if the running time was an extra 6 seconds I'd still rather > spend 4% more running time to use 1/2 the storage space. > > > diff --git a/pack-objects.c b/pack-objects.c > index 09f4f2c..f7d6217 100644 > --- a/pack-objects.c > +++ b/pack-objects.c > @@ -1052,7 +1052,7 @@ static int try_delta(struct unpacked *cu > if (cur_entry->delta) > max_size = cur_entry->delta_size-1; > if (sizediff >= max_size) > - return -1; > + return 0; > delta_buf = diff_delta(old->data, oldsize, > cur->data, size, &delta_size, max_size); > if (!delta_buf) -- Shawn. - : 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