On 9/9/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
In contrast, doing some of the same sorting that git-rev-list already does in the consumer instead, is obviously duplicating the same basic notions, but once you do it in the consumer, you can suddenly do things that simply weren't possible in git-rev-list - do things incrementally, and then if you notice half-way that you did something wrong, you can go back and fix it up (which can be quite acceptable). That just isn't an option in a linear environment like the git-rev-list output.
Perhaps is total idiocy but why do not implement the fix-up logic directly in git-rev-list? 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. Instead of changing drwing logic is then enough to add a fixup routine that cycles through out of order commits and updates the graph. This also avoids recursive reordering where perhaps the same part of a graph should be redrawn more then one time due to differtent new parents to the same child arrives at different times. 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