So one of my coworkers accidentally made a merge that actually only kept one side of the tree. So he started a merge, deleted all the changes introduced by the merge, and then committed the merge.
Here is a simple test case I did on a test repo. This repo has three branches. idx is the topic branch that was accidentally merged, and master is the mainline. dev is just a test of how revert -m works so you can ignore it.
What I want to do is revert the faulty merge. So from master I try to run git revert -m 1 <sha1sum of faulty merge>
but then git responds with:
# On branch master
nothing to commit (working directory clean)
So it doesn't actually create a revert commit that undoes the merge. I believe that this happens because the merge didn't actually contain any real changes.
Is this a git bug, or am I missing something?
The best rule of thumb here is to never ever change the history of your repo after it has been made public. It really screws things up. I don't think this case can avoid it though.
I think there are a couple of options here but the simplest is to do a rebase. Using your repo, these are the commands I used:
git rebase -i ead3646
Then, when the interactive shell comes up, remove the entire line of the faulty commit. Save that and you should wind up with a new history like this:
* f0ab6d5 more normal work on dev
* ebb5103 idx commit
* ead3646 master change
* 582c38c dev commits
* f4b8bc6 initial commit
Getting you two (and others) back in sync is going to take some branching, pushing, emailing and lunch buying.