path: root/merge-recursive.c
diff options
authorJohannes Schindelin <>2006-08-09 20:30:58 (GMT)
committerJunio C Hamano <>2006-08-09 21:57:22 (GMT)
commit8918b0c9c2667c5a69461955135c709b09561f72 (patch)
tree6f811bdeef0498aecd98d3de9f7d18937f6b7b78 /merge-recursive.c
parent934d9a24078e65111e9946ad3449c3fa9c06475e (diff)
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 <>
Diffstat (limited to 'merge-recursive.c')
1 files changed, 12 insertions, 1 deletions
diff --git a/merge-recursive.c b/merge-recursive.c
index d4de1ad..9281cd1 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);
- 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)