7

So we've gotten a git branch into a tricky state:

Two branches: 

* master * other_branch

Last week someone accidentally merged other_branch (prematurely) onto master and pushed to origin. We noticed the error and I, in my naivete, committed 

 git revert bad_merge_commit

to "fix" the problem. Everything looked ok, we moved on with our lives...

Today we attempted to merge master into other_branch as a step towards bringing other_branch into master. But my revert seems to have caused a nightmare. When master merges into other_branch, all (most?) of the work on other_branch is deleted. I presume this is because my revert instructs all the older commits to be reverted.

There are of course now many days' worth of commits on master on top of my revert, so untangling this looks like it may be difficult.

Is there some way to repair the damage? Can I perhaps reach in with some rebasing argument and delete the two offending commits?

Many thanks!

[Update - adding detail of current state as requested]

other_branch was branched off of master quite some time ago. Our standard practice is to merge master repeatedly into other_branch as we go to minimize buildup of conflicts (sometimes we rebase, but not in this case).

master commits A | B | C | BAD_MERGE [other_branch_@S] | REVERT_OF_BAD | D | E | F ... HEAD

other_branch commits P | Q | R | S [BAD_MERGE_FROM_HERE] | T | U | V ... HEAD

Attempt to merge master HEAD to other_branch HEAD causes problem.

Charles, I'm currently attempting a fix on a duplicate of master using the solution you suggested here: How to remove selected commit log entries from a Git repository while keeping their changes?.

[/Update]

Improve this question
1
  • Can you state (preferably with explicit pictures) exactly what state you are in at the moment? It shouldn't be too difficult to fix but it sounds like you may need to repair the damage cause my your first (recent) attempt to merge master to other_branch if this is committed and pushed. Commented Mar 24, 2011 at 7:46

1 Answer 1

Reset to default
4

Yes, the problem is that the revert undid the changes introduced by the merge, but not merge itself. I think the addendum section of https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html describes a possible solution.

This document is also part of Git, under Debian you will find it at /usr/share/doc/git-doc/howto/revert-a-faulty-merge.txt

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thanks, it looks like this describes our case very exactly. I need to read and absorb. Will get back as soon as I've done so. :)
Yes the rebase --no-ff described in there seems like the key. We've got some work ahead of us, but I think you've pointed me in the correct direction. Thanks! (This does leave me with the follow-up question: what should I have done to undo the bad merge and avoid this scenario, bearing in mind that someone else had already pushed it to origin?)
The link to code.google.com appears to no longer have the desired content.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.