From 8918b0c9c2667c5a69461955135c709b09561f72 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 9 Aug 2006 22:30:58 +0200 Subject: [PATCH] merge-recur: try to merge older merge bases first 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 Signed-off-by: Junio C Hamano --- merge-recursive.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/merge-recursive.c b/merge-recursive.c index d4de1adfe2..9281cd183a 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -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)