diff options
| author | Johannes Schindelin <Johannes.Schindelin@gmx.de> | 2006-08-09 22:30:58 +0200 |
|---|---|---|
| committer | Junio C Hamano <junkio@cox.net> | 2006-08-09 14:57:22 -0700 |
| commit | 8918b0c9c2667c5a69461955135c709b09561f72 (patch) | |
| tree | 6f811bdeef0498aecd98d3de9f7d18937f6b7b78 /builtin-rev-list.c | |
| parent | 934d9a24078e65111e9946ad3449c3fa9c06475e (diff) | |
| download | git-8918b0c9c2667c5a69461955135c709b09561f72.tar.gz | |
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 <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'builtin-rev-list.c')
0 files changed, 0 insertions, 0 deletions