On Thu, 29 Jun 2006, Jeff King wrote: > On Thu, Jun 29, 2006 at 03:04:15PM -0400, Nicolas Pitre wrote: > > > Right. Your use pattern is a special case that doesn't work well with > > the whole window hash approach. I'd expect it to work beautifully with > > the kernel repository though. > > I don't necessarily care about the kernel repository. It packs fine as > it is, and you only waste 30 seconds on a repack checking deltas that > could be avoided. I do care on my special repository where packing is > virtually unusable and I can achieve a 45x speedup. Maybe my original > caching is not worth it for the kernel and should be configurable, > but obviously this window caching cannot REPLACE mine since it fails > utterly for the one thing I wanted it for. And I agreed with you already. > That being said, I'm not sure that window caching is all that great for > "normal" repos. > > Same test as before, but instead of simulating the commits, I merely > looked at the window hashes produced by > git-rev-list --objects master~$x > > For the git repo: > x=0 tries 6698 windows > x=0 and x=50 contain 5197 identical windows > x=0 and x=100 contain 2484 identical windows > x=0 and x=500 contain 455 identical windows > > For linux-2.6 repo: > x=0 tries 57208 windows > x=0 and x=50 contain 53677 identical windows > x=0 and x=100 contain 52886 identical windows > x=0 and x=500 contain 41196 identical windows > > 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. 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. Nicolas - : 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