On 11/2/07, Paul Mackerras <paulus@xxxxxxxxx> wrote: > > In any case, no that's not the only reason. The main reason is that > it (i.e. --topo-order) spits out the commits in exactly the order that > gitk wants to display them (of which the bit about parents coming > after all their children is a part), and thus reduces the amount of > processing I need to do in Tcl. > I have tried to overcome --topo-order in qgit but I found it very difficult, too much for me. Lazily drawing the layout it doesn't mean that you lazy load the data from git, indeed you load all the git-log output as soon as it arrives. And if the revisions arrive "in order", i.e. if revision A arrive before revision B it means that A is NOT an ancestor of B, this is of great help. When drawing the graph assuming that the vector/list of the arrived sha is already ordered greatly simplify the whole thing, if we relax this hypothesis then a lot of work should be done before to draw a graph chunk, essentially the GUI tool needs to walk the _entire_ list and reorder it by itself _before_ to draw any graph chunk also if very small. So at the end you end up transferring the complete revision walk from git-log to the GUI tool, and (this is the important thing) to be sure graph is always correct you need to perform the walk _before_ drawing any stuff. The only possible _trick_ I was able to find is to optimistically draw the graph chunk _assuming_ that it is ordered. Then reorder the list in the background and finally check if the graph is correct, if not redraw with correct data. If the out of order revisions are rare you end up mimic a fast correct drawing. If are not user will see some flickering at the end of the load. IMHO the above scheme is very complicated and fragile. Just my two cents. Marco - 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
