Hi,
On Fri, 7 Aug 2009, Nicolas Pitre wrote:
On Fri, 7 Aug 2009, Sam Vilain wrote:
quoted
Johannes Schindelin wrote:
quoted
quoted
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