But can we stop designing git-rev-list output formats until we've figured out if and how to implement it in the visualizer? Or, more to the point, visualizers plural. That's the hard part. Then we can see what sort of git-rev-list output would be most convenient.
Regarding qgit we have two cases: -arrive of fixup set for out of order commits _not_ currently displayed on the screen This is by far the most common case expecially for big archives. In this case the fix speed depends on how far are the fixed commits from the last loaded commit (it's an insertion in a vector). In any case far more quick then redrawing the graph. No flickering side effect here. Implementation is easy. -arrive of fixup set for out of order commits currently displayed on the screen Here implementation _could_ be more difficult, but given the very low statistic of this case (a rare case among rare cases) we could accept the brutal approach of reset the complete graph, *but not the loaded revisions data*, and redraw the graph. With this approach implementation is almost as easy as before but flickering is involved. I agree with you that we should have fixup information as soon as git-rev-list discovers out of order commits. 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