[RFC PATCH] Why doesn't git rebase --interactive --preserve-merges continue past known conflicts?
David D. Kilzer <ddkilzer <at> kilzer.net>
2011-01-02 01:20:02 GMT
On 2010-12-31, David Kilzer wrote:
> When I run "git rebase --interactive --preserve-merges" on a sequence of
> commits, edit an earlier commit, then run "git rebase --continue", the rebase
> operation always stops on a merge commit with a known conflict (in the rr-cache)
> instead of resolving it and continuing.
> As long as I'm not rearranging commits, I expect git-rebase to resolve the known
> merge commit conflict and continue. Why does it always stop?
Here's a very rough patch that fixes my original test case so that an interactive
rebase won't stop when git-rerere knows how to resolve all conflicts during a
However, if there are any changes to a non-conflicted file during the original
merge commit, they will be lost when rebasing, even with --preserve-merges.
Note that this occurs even without this patch applied. You must compare the
current commit with original being rebased to make sure they're not lost.
Why doesn't an interactive rebase serialize to disk all of the changes in a merge
commit like it does for non-merge commits?
rebase--interactive.sh | 11 ++++-
t/t3404-rebase-interactive-preserve-merges.sh | 64 +++++++++++++++++++++++++
2 files changed, 73 insertions(+), 2 deletions(-)
create mode 100755 t/t3404-rebase-interactive-preserve-merges.sh
diff --git a/git- rebase--interactive.sh b/git- rebase--interactive.sh
index a5ffd9a..32375bc 100755