Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled

[Johannes Sixt <j6t@kdbg.org>]

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