Fix git-rev-list "date order" with --topo-order

This fixes git-rev-list so that when there are multiple branches, we still
sort the heads in proper approximate date order even when sorting the
output topologically.

This makes things like

	gitk --all -d

work sanely and show the branches in date order (where "date order" is
obviously modified by the paren-child dependency requirements of the
topological sort).

The trivial fix is to just build the "work" list in date order rather than
inserting the new work entries at the beginning.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/commit.c b/commit.c
index 534c03ea59efc3898857e4853536ec4f4c189937..ebf4db6416497ba6586d359c6d37c8ee942a1395 100644 (file)
--- a/commit.c
+++ b/commit.c
@@ -536,7 +536,7 @@ int count_parents(struct commit * commit)
 void sort_in_topological_order(struct commit_list ** list)
 {
        struct commit_list * next = *list;
-       struct commit_list * work = NULL;
+       struct commit_list * work = NULL, **insert;
        struct commit_list ** pptr = list;
        struct sort_node * nodes;
        struct sort_node * next_nodes;
@@ -580,11 +580,12 @@ void sort_in_topological_order(struct commit_list ** list)
          * the tips serve as a starting set for the work queue.
          */
        next=*list;
+       insert = &work;
        while (next) {
                struct sort_node * node = (struct sort_node *)next->item->object.util;
 
                if (node->indegree == 0) {
-                       commit_list_insert(next->item, &work);
+                       insert = &commit_list_insert(next->item, insert)->next;
                }
                next=next->next;
        }