Hi, On Fri, 7 Aug 2009, Nicolas Pitre wrote: > On Fri, 7 Aug 2009, Sam Vilain wrote: > > > Johannes Schindelin wrote: > > >> the short answer is that cache slices are totally independant of > > >> pack files. > > >> > > > > > > My idea with that was that you already have a SHA-1 map in the pack > > > index, and if all you want to be able to accelerate the revision > > > walker, you'd probably need something that adds yet another mapping, > > > from commit to parents and tree, and from tree to sub-tree and blob > > > (so you can avoid unpacking commit and tree objects). > > > > > > > Tying indexes together like that is not a good idea in the database > > world. Especially as in this case as Nick mentions, the domain is > > subtly different (ie pack vs dag). Unfortunately you just can't try to > > pretend that they will always be the same; you can't force a full > > repack on every ref change! > > Right. And the rev cache must work even if the repository is not > packed. Umm, why? AFAICT the principal purpose of the rev cache is to help work loads on, say, www.kernel.org. I am unlikely to notice the improvements in my regular "git log" calls that only show a couple of pages before I quit the pager. Ciao, Dscho -- To unsubscribe from this list: 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