Sometimes you get merge conflicts when rebasing complicated repositories. It doesn’t always happen but it seems to be when existing conflicted merges are resolved. If you’re sure that your rebase doesn’t really conflict with anything in your repository, then you can tell the merge strategy to pick the new change using the following command:
git rebase -s recursive -X theirs master
This just picks the state in the new patch; in other words the diff will reflect the new changes plus any merge resolutions.
It’s still possible to see conflicts when files are deleted and modified in a merge conflict, however you can resolve this with
git checkout --theirs FILE ; git add FILE.
I’m not completely sure on why this situation occurs. I think git is simply being safe about how it treats the patches in the history. What we’re doing here is pretending the merge solution never happened and that all commits played well with each other which is not the case in reality. Therefore this command is destroying the history of patches as they actually happened. I’m merging extremely old repositories that have very messy histories anyway so it’s difficult for me to assess the impact of this other than to say that the log looks OK and the files are as they should be.
If all you’re looking for is a nice output of
git blame and a bisectable history then this method should be OK for you.