Linus Torvalds writes: > (And as mentioned many times earlier - if you can avoid topo-order and > date-order entirely, you are going to perform a million times better at > startup for the cold-cache case. Since you seem to be doing the graph > layout lazily now, maybe you could aim for that some day? It does mean > that you might - occasionally - end up having to add a commit to > *before* one you already laid out). The other thing --topo-order does is reorder the commits so that related commits come together. So far, doing that in Tcl has turned out to be much slower than having it done in C (within git log) for the hot-cache case (which I expect is the common case). I'm now thinking that the best approach would be to have gitk cache the topology, and on startup only read in the part of the graph that isn't in the cache. Mostly that will be small and so git log should be fast even in the cold-cache case with --topo-order. Paul. - 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
