Working Around Merge Conflicts In a Git Rebase

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.

Working Around Merge Conflicts In a Git Rebase

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s