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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html