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>
---

This should also fix this report, although Matthias should double-test..

On Mon, 14 Nov 2005, Matthias Urlichs wrote:

quoted

          $ gitk $(cd .git/lost+found/commit && echo ??*)

Along those lines... I just tried that, it found a whole heap of old
commits I didn't yet clean up, and they're sorted by their SHA1.

In other words, actually finding the latest commit in there was a
nontrivial task.

I don't speak tcl, so could somebody please change "gitk -d" to sort its
command line by date (newest first, of course)?  Thanks.

diff --git a/commit.c b/commit.c
index 534c03e..ebf4db6 100644
--- 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 co
          * 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;
 	}