Linus Torvalds <torvalds@xxxxxxxx> writes: > On Thu, 29 Jun 2006, Nicolas Pitre wrote: >> >> The negative delta cache concept is certainly attractive even for normal >> repositories, especially for public servers, since when used in >> conjonction with delta reuse it makes the creation of a pack basically >> free. So I think this idea really has merits, as long as the cache >> remains small. > > I don't really see much of a point of this all. > > Instead of having a separate cache, wouldn't it be much better to just > take the hint from the previous pack-file? > > In the repacking window, if both objects we are looking at already came > from the same (old) pack-file, don't bother delta'ing them against each > other. > > That means that we'll still always check for better deltas for (and > against!) _unpacked_ objects, but assuming incremental repacks, you'll > avoid the delta creation 99% of the time. > > Ie somethng really simple like the appended. > > Linus > --- > diff --git a/pack-objects.c b/pack-objects.c > index bed2497..cea63e7 100644 > --- a/pack-objects.c > +++ b/pack-objects.c > @@ -988,6 +988,13 @@ static int try_delta(struct unpacked *tr > return -1; > > /* > + * We do not bother to try a delta that we discarded > + * on an earlier try > + */ > + if (trg_entry->in_pack && trg_entry->in_pack == src_entry->in_pack) > + return -1; > + > + /* I think you meant to return 0 from here though. -1 means "do not use this pair and do not bother try improving it with the remaining candidates". - : 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