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

From: Jon Seymour <jon.seymour@gmail.com>
Date: Jun 20, 2005, 02:29 UTC
Message-ID: <20050620022936.28620.qmail@blackcubes.dyndns.org>

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

 epoch.c |   35 +++++++++++++++++++++--------------
 1 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -621,20 +621,27 @@ int sort_list_in_merge_order(struct comm
 			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;
+				}
 			}
 		}
 
------------