merge-recur: try to merge older merge bases first
authorJohannes Schindelin <Johannes.Schindelin@gmx.de>
Wed, 9 Aug 2006 20:30:58 +0000 (22:30 +0200)
committerJunio C Hamano <junkio@cox.net>
Wed, 9 Aug 2006 21:57:22 +0000 (14:57 -0700)
It seems to be the only sane way to do it: when a two-head merge is
done, and the merge-base and one of the two branches agree, the
merge assumes that the other branch has something new.

If we start creating virtual commits from newer merge-bases, and go
back to older merge-bases, and then merge with newer commits again,
chances are that a patch is lost, _because_ the merge-base and the
head agree on it. Unlikely, yes, but it happened to me.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-recursive.c

index d4de1adfe271c57ff40f60b4064de9ae35980599..9281cd183a8913278f0944c4dc5da9b520d8274b 100644 (file)
@@ -1191,6 +1191,17 @@ static int merge_trees(struct tree *head,
        return clean;
 }
 
+static struct commit_list *reverse_commit_list(struct commit_list *list)
+{
+       struct commit_list *next = NULL, *current, *backup;
+       for (current = list; current; current = backup) {
+               backup = current->next;
+               current->next = next;
+               next = current;
+       }
+       return next;
+}
+
 /*
  * Merge the commits h1 and h2, return the resulting virtual
  * commit object and a flag indicating the cleaness of the merge.
@@ -1216,7 +1227,7 @@ int merge(struct commit *h1,
        if (ancestor)
                commit_list_insert(ancestor, &ca);
        else
-               ca = get_merge_bases(h1, h2, 1);
+               ca = reverse_commit_list(get_merge_bases(h1, h2, 1));
 
        output("found %u common ancestor(s):", commit_list_count(ca));
        for (iter = ca; iter; iter = iter->next)