> If the out of order revisions are a small amount of the total then > could be possible to have something like > > git rev-list --topo-order --with-appended-fixups HEAD > > Where, while git-rev-list is working _whithout sorting the whole tree > first_, when finds an out of order revision stores it in a fixup-list > buffer and *at the end* of normal git-rev-lsit the buffer is flushed > to receiver, so that the drawing logic does not change and the out of > order revisions arrive at the end, already packed, sorted and prepared > by git-rev-list. I don't think I understand your proposal. The problem arises when git-rev-list finds a commit that it should have listed before something that it has already output. Just for example: Commit D: Ancestor B Commit B: Ancestor A Commit C: Ancestor B Commit C is the problem, because if git-rev-list has already output B, there's no way to back up and insert it in the right place. How is waiting to output the already-behind-schedule commit C going to help anything? The idea in gitk is to rewind the layout algorithm to before B was added, insert C, and replay from there. This is most efficient if C is encountered as soon after its correct place as possible. - 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