Skip to content

Commit

Permalink
merge-recur: try to merge older merge bases first
Browse files Browse the repository at this point in the history
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>
  • Loading branch information
Johannes Schindelin authored and Junio C Hamano committed Aug 9, 2006
1 parent 934d9a2 commit 8918b0c
Showing 1 changed file with 12 additions and 1 deletion.
13 changes: 12 additions & 1 deletion merge-recursive.c
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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)
Expand Down

0 comments on commit 8918b0c

Please sign in to comment.