Benny Halevy wrote:
I'm hitting bad merges with (non interactive) git rebase
when a hunk is merged pre-maturely into an inexact match
when there's fuzz.
[...]
{ for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
[...]
git rebase --onto test_branch master^ master
git-am, and by extension rebase, by default doesn't take history into
account. It just applies the patches "blindly". Thus, there's no way
to know which series of 'line N' you really wanted it to go onto.
To avoid this issue, use the -m option to git-rebase so that it uses a
"real" merge. (You can achieve similar effects for git-am with the -3
option.)
--
Thomas Rast
trast@{inf,student}.ethz.ch