| commit | 8918b0c9c2667c5a69461955135c709b09561f72 | |
| author | Johannes Schindelin <Johannes.Schindelin@gmx.de> | |
| Wed, 9 Aug 2006 20:30:58 +0000 (9 22:30 +0200) | ||
| committer | Junio C Hamano <junkio@cox.net> | |
| Wed, 9 Aug 2006 21:57:22 +0000 (9 14:57 -0700) | ||
| tree | 6f811bdeef0498aecd98d3de9f7d18937f6b7b78 | treesnapshot (tar.gz zip) |
| parent | 934d9a24078e65111e9946ad3449c3fa9c06475e | commitdiff |
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>
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>
| merge-recursive.c | diffblobblamehistory |