Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jun 18, 2012, 19:06 UTC
- Message-ID
- <4FDF7C3C.90300@kdbg.org>
- In-Reply-To
- <B5E2DD4F-4EEB-4440-A149-DD718B0C2EFD@kilzer.net>
Am 17.06.2012 23:30, schrieb David Kilzer:
Show 28 quoted lines
> 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