On Fri, 8 Sep 2006, Jon Smirl wrote: > > gitk would need to be modified to only run enough of the commit tree > to draw what is displayed in the window. As you page down it would > retrive more commits if needed. There is no need for gitk to run 250K > commits when I'm usually never going to look at them all. Of course > this may mean some rework for gitk. Actually, it's more than a little rework. The _real_ problem is that gitk uses "--topo-order" to git-rev-list, which basically means that git-rev-list needs to parse EVERY SINGLE COMMIT. So far, nobody has written a topological sort that can reasonably efficiently handle partial trees and automatically notice when there is no way that a DAG cannot have any more references to a commit any more (if you can show that the result would cause a cycle, you could output a partial topological tree early). It's possible that no such topological sorting (ie the efficient kind, that can work with partial DAG's) even exists. So if you want to be able to visualize a partial repository, you need to teach git to not need "--topo-order" first. That's likely the _big_ change. After that, the rest should be easy. [ One way to do it might be: the normal ordering of revisions without "--topo-order) is "_close_ to topological", and gitk could just decide to re-compute the whole graph whenever it gets a commit that has a parent that it has already graphed. Done right, it would probably almost never actually generate re-computed graphs (if you only actually generate the graph when the user scrolls down to it). Getting rid of the --topo-order requirement would speed up gitk absolutely immensely, especially for unpacked cold-cache archives. So it would probably be a good thing to do, regardless of any shallow clone issues ] Hmm? Linus - 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