[PATCH] Prevent git-rev-list --merge-order producing duplicates in the output

If a is reachable from b, then git-rev-list --merge-order b a would
produce a duplicate output of b.

This causes a problem for an upcoming version of gitk since it
breaks the --merge-order ordering invariant.

This patch fixes the problem for the --merge-order switch. A subsequent
patch will fix the problem for the non --merge-order switch.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff --git a/epoch.c b/epoch.c
index fdfaddafbcba305caa0ed092b16c7e960fd45b36..35756a37ee13a752f73568c4570250aa28bf8afa 100644 (file)
--- a/epoch.c
+++ b/epoch.c
@@ -621,20 +621,27 @@ int sort_list_in_merge_order(struct commit_list *list, emitter_func emitter)
                        base->object.flags |= BOUNDARY;
 
                while (reversed) {
-                       sort_first_epoch(pop_commit(&reversed), &stack);
-                       if (reversed) {
-                               /*
-                                * If we have more commits to push, then the
-                                * first push for the next parent may (or may
-                                * not) represent a discontinuity with respect
-                                * to the parent currently on the top of
-                                * the stack.
-                                *
-                                * Mark it for checking here, and check it
-                                * with the next push. See sort_first_epoch()
-                                * for more details.
-                                */
-                               stack->item->object.flags |= DISCONTINUITY;
+                       struct commit * next = pop_commit(&reversed);
+
+                       if (!(next->object.flags & VISITED)) {
+                               sort_first_epoch(next, &stack);
+                               if (reversed) {
+                                       /*
+                                        * If we have more commits 
+                                        * to push, then the first
+                                        * push for the next parent may 
+                                        * (or may * not) represent a 
+                                        * discontinuity with respect
+                                        * to the parent currently on 
+                                        * the top of the stack.
+                                        *
+                                        * Mark it for checking here, 
+                                        * and check it with the next 
+                                        * push. See sort_first_epoch()
+                                        * for more details.
+                                        */
+                                       stack->item->object.flags |= DISCONTINUITY;
+                               }
                        }
                }