Re: [RFC] Cache negative delta pairs
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:31
Linus Torvalds [off-list ref] writes:
quoted hunk
On Thu, 29 Jun 2006, Nicolas Pitre wrote:quoted
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".