Am 17.06.2012 23:30, schrieb David Kilzer: > 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 Don't do that then ;) Enter your favorite git.git clone, then git pull git://repo.or.cz/git/mingw/j6t.git preserve-merges-by-cherry-pick should work like a charm. But I've now removed the branches that needed the missing commit, and your command should work as well. -- Hannes -- 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