Linus Torvalds writes: > [ 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? I recently added code to gitk to add extra commits after the graph has been laid out, provided that the extra commits have one parent and no children. If I generalized that to handle arbitrary numbers of parents and children, it might go close to what you're suggesting. It might get nasty if we have laid out A and then later B, and then C comes along and turns out to be a child of A but a parent of B, meaning that both B and C have to be put above A. Another thing I have been thinking of is that gitk probably should impose a time limit of say 3 months by default, unless the user specifies some other ending condition (such as commitid.., ^commitid or --since=something-else). Together with a menu to select the time limit, I think that would be quite usable and would make gitk start up *much* faster. 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