On Sat, 9 Sep 2006, Paul Mackerras wrote: > > > The menu would help, of course. But it would be even nicer if you'd be > > able to make do without the --topo-order. > > The graph does seem to look a little nicer with --topo-order, in that > it tends to do a whole string of commits on a single branch in a > bunch, whereas without --topo-order it seems to hop from branch to > branch more. Yeah, see "--date-order". It's topologically sorted, but within that topological sort it is in the "date order", which approximates the normal non-sorted output. Without sorting, you also won't see any sorting by branch, although it could be done by the consumer of the rev-list data (ie you could do it in gitk, similarly to how you'd effectively do a topological sort of your own). So it actually boils down to the exact same thing: - git-rev-list doing whatever sorting is "convenient", in that it's the one common interface to git revisions, so once you do it there, you do it for everybody. - however, for much the same reason, git-rev-list by definition doesn't know _who_ it is sorting things for, or how it's going to be visualized (exactly because it's the "one convenient central place", of course), and as a result it needs to not only get the right answer, it needs to get it on the first try and can't go back incrementally to fix up the list of commits. So the convenience of doing any kind of sorting in git-rev-list is by definition also the thing that causes it to have bad latency, in that it needs to parse the _whole_ history. 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. Linus - 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