# [PATCH] merge-recur: try to merge older merge bases first 1 messages from 2006-08-09 to 2006-08-09. Participants: Johannes Schindelin. Thread: https://gitlist.dev/t/5187 ## Johannes Schindelin, 2006-08-09 20:30 Subject: [PATCH] merge-recur: try to merge older merge bases first Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0608092221590.13885%40wbgn013.biozentrum.uni-wuerzburg.de ``` 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 --- merge-recursive.c | 16 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletion(-) diff --git a/merge-recursive.c b/merge-recursive.c index f5b547b..2d3ab4f 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,8 @@ 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)); + //ca = get_merge_bases(h1, h2, 1); output("found %u common ancestor(s):", commit_list_count(ca)); for (iter = ca; iter; iter = iter->next) -- 1.4.2.rc3.g29d0-dirty ```