Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled
- From
David Kilzer <ddkilzer@kilzer.net>
- Date
- Jun 17, 2012, 21:30 UTC
- Message-ID
- <B5E2DD4F-4EEB-4440-A149-DD718B0C2EFD@kilzer.net>
- In-Reply-To
- <4FDE2252.5030802@kdbg.org>
On Jun 17, 2012, at 11:30 AM, Johannes Sixt wrote:
Show 15 quoted lines
> 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