Linus Torvalds writes: > It's disgusting. But it avoids the unnecessary data transfer - except for > just the first 100 commits that get sent twice. And it gets what *I* look > for, namely that "immediate" feel to the initial pop-up of the history. Yes. And it avoids the need for gitk to have to do any re-ordering of the commits that it gets from git log. In the case where the first commits come out in a different order in the final list, gitk can just truncate its list at the point of difference and re-read from there, which is a lot less time-consuming than having to make a decision for every commit about where it should go in the list. I have actually been trying to come up with a decent way to generate the list incrementally without using --topo-order for months now. One of the problems is that while Tcl can append things to the end of a long list efficiently, and can index long lists efficiently, inserting things into the middle of a long list is slow. That makes any insertion-sort type of algorithm unbearably slow. And it's not just when we get parents before children that I have to insert into the middle of the list -- reordering a date-order list into one where we see the string of commits that were merged immediately after a merge commit requires a lot of insertions. I do have an approach that I'm thinking about that builds up the list as a series of "arcs", each of which is a string of commits with exactly one parent and one child. Each new commit from git log (without --topo-order) then either gets appended to an arc (there can be several arcs that are still growing at any given point), or it is a merge or a branch point, which means it terminates some arc(s) and/or starts new arc(s). The final list of commits is then composed by concatenating the arcs in a suitable order. That avoids doing insertions but does make things more complex for the consumers of the list (the layout algorithm and the search function), and it potentially makes it much slower to go from a row number to the commit displayed on that row. However, for now I think that using --early-output is a good compromise solution that makes the startup much faster (or at least *appear* to be much faster :) without adding much complexity. Regards, Paul. - 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
