On Jun 17, 2012, at 11:30 AM, Johannes Sixt wrote: > Am 17.06.2012 15:46, schrieb David Kilzer: >> If it could be guaranteed that all changes in a merge commit would be >> preserved when running "git rebase -i -p" with rerere.autoupdate >> enabled, I think that would be an argument for not returning control >> to the user during the rebase operation. However, changes to >> non-conflicted files in a merge commit are currently lost in this >> case, so it would be too dangerous to enable this behavior now. > > You can test this patch: > > git://repo.or.cz/git/mingw/j6t.git preserve-merges-by-cherry-pick > > I think it suits you needs unless you run into the one use-case where > the patch is a regression (as documented by the new test_expect_failure > in the test suite). I'd love to try it, but I'm running into an issue pulling the repository: $ git clone git://repo.or.cz/git/mingw/j6t.git -b preserve-merges-by-cherry-pick j6t.git Cloning into 'j6t.git'... remote: error: Could not read 942cf39b9a36ae27a4377d22093827ef4df25239 remote: fatal: Failed to traverse parents of commit 051ba02462dd65a0ceb3e527a75f24416378880f remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed $ git --version git version 1.7.9.6 (Apple Git-31) Dave -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html