Thread (27 messages) flat view 27 messages, 6 authors, 2016-06-15

Re: [RFC] Cache negative delta pairs

From: Jeff King <hidden>
Date: 2016-06-15 22:42:31

Possibly related (same subject, not in this thread)

On Thu, Jun 29, 2006 at 04:24:01PM -0400, Nicolas Pitre wrote:
quoted
Obviously the kernel repo is doing better, but x=500 is only 4 days ago.
Trying with --before=2.weeks.ago yields only 31505 matches.
What does this prove?  I fail to see the relation between those results 
and a possible git-pack-objects improvement.
My point is that the window cache gets invalidated over time, whereas a
sha1 by sha1 cache doesn't.  However, the point is moot, as I think
Linus has come up with a much better solution.
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.
Yes, if you're talking about a situation in which you make many packs
for a given set of commits, then it does make more sense (what I was
really trying to eliminate was a 10 minute repack followed by another 10
minute repack to push to the server).

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help