Git: how to revert a branch merge without overwriting history?

Question

I have two branches: master and opengl. I recently finished implementation (or at least I thought so) of opengl branch and decided to merge it into master:

git checkout master
git merge opengl
git push

After I did this, several developers who are working on the master branch pulled my changes and it turned out that my implementation conflicted with some of their code. Therefore I would like to revert the merge operation on the master branch, but without overwriting history.

Note that I would like to be able to merge the opengl branch into master eventually (after I fix all the bugs). Therefore simply checking out older version of master and committing it will not work - newly created commit will cancel my changes from opengl when I will try to merge it.

Thank you.

Solution 1

The documentation "How to revert a faulty merge" mentioned by cebewee explains why a git revert is tricky when reverting a merge.

So the merge will still exist, and it will still be seen as joining the two branches together, and future merges will see that merge as the last shared state - and the revert that reverted the merge brought in will not affect that at all.
If you think of "revert" as "undo", then you're going to always miss this part of reverts.
Yes, it undoes the data, but no, it doesn't undo history.

git revert is the right solution here, but it will have a consequence in the future, when you want to merge that branch again.
The next merge will then have to "revert the revert" first, and then merge the branch.

Solution 2

Edit: This turns out not to be what the OP asked for, but I'll keep it here in case someone should happen to look for a solution that does involve rewriting history.

---

First, create a new branch if you want to keep the merge commit locally, so that the commit doesn't "disappear" after you move master:

git branch erroneousMerge master

If the other developers have also made commits after the erroneous merge, they must do this as well!

Then, reset master to refer to the last commit before the merge; let's say that it's commit e498b2...:

git checkout e498b2
git branch -f master

Now, you can push the corrected master (-f indicates that you want to make the server reset its master branch to the commit that you have made it point to, even though this commit is an ancestor of the one it points to in the repository):

git push -f origin master

Now, the other developers can update their master to match that of the server(-f indicates that they accept that the branch has moved backwards):

git fetch -f origin master:master

If the other developers have made changes after the erroneous merge (let's say that the merge commit is abc123, they can use rebase to move the changes to the corrected master:

git rebase --onto master abc123 oldMaster

If you screw up at some point and end up with "losing" commits because there is no longer any branches pointing to them, you can use git fsck --lost-found to recover them.

Comments

[Lars Noschinski]

Maybe kernel.org/pub/software/scm/git/docs/howto/… helps?

[Sergiy Belozorov]

What you are suggesting is exactly overwriting history. I would like to avoid this, because there are too many people who are using repository and all of them will have to perform this operation. I am sure there is a better way.

[Aasmund Eldhuset]

You could create a new commit that reverses the effects of the merge commit by using git revert (also described in the link @cebewee posted).

[Carlos Campderrós]

I'd like to emphasize the last two phrases, because they are very important (and easy to miss and then do not understand the consequences of not reverting the revert commit.)

[VonC]

See also git-scm.com/blog/2010/03/02/undoing-merges.html, which has a "Reverting the Revert" section