Re: Converting merge to rebase in the presence of conflicts

["Hrvoje Nikšić" <hniksic@gmail.com>]

Thanks for the responses, rerere works nicely, if somewhat cryptic. At
the rebase step I got:

First, rewinding head to replay your work on top of it...
Applying: changed2
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging a
CONFLICT (content): Merge conflict in a
Resolved 'a' using previous resolution.
Failed to merge in the changes.
Patch failed at 0001 changed2

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

That's a lot of output, some of it scary-looking. (OK, maybe not
scary-looking to me, but certainly so to someone not yet fully
comfortable with git.)  Running "git rebase --continue" told me I
needed to "edit all merge conflicts and then mark them as resolved",
whereas the conflicts are in fact already resolved, but rebase doesn't
know it.  Again, this isn't a big problem for me, but it's unfriendly.
 "git add" followed by "git rebase --continue" worked exactly as I
hoped it would.

I still wonder why rerere is necessary here. After all, even without
the rerere metadata, the information about conflict resolution is
right there, in the merge commit, and rebase could conceivably make
use of it. What am I missing?

Hrvoje