Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

So imagine the following the happens (and that we're all using SourceTree):

  1. We're all working off origin/develop.
  2. I go on holiday for a week.
  3. My coworker has been working locally for the past several days without merging origin/develop back in to his local develop branch.
  4. He tries to do a push, gets told he has to merge first, and then does a pull.
  5. He gets a conflict, stopping the automatic commit-after-a-merge from proceeding.
  6. Assuming that Git is like SVN, my coworker discards the "new" files in his working copy and then commits the merge - wiping those "new" files from the head of origin/develop.
  7. A weeks worth of dev work goes on on top of that revision.
  8. I come back from holidays and find out that several days of my work is missing.

We're all very new to Git (this is our first project using it), but what I did to fix it was:

  1. Rename "develop" to "develop_old".
  2. Merge develop_old into a new branch "develop_new".
  3. Reset the develop_new branch to the last commit before the bad merge.
  4. Cherry pick each commit since then, one by one, resolving conflicts by hand.
  5. Push develop_old and develop_new up to the origin.

At this point, develop_new is, I'm hoping, a "good" copy of all of our changes with the subsequent weeks worth of work reapplied. I'm also assuming that "reverse commit" will do odd things on a merge, especially since the next few weeks worth of work is based on it - and since that merge contains a lot of things we do want along with stuff we don't.

I'm hoping that this never happens again, but if it does happen again, I'd like to know of an easier / better way of fixing things. Is there a better way of undoing a "bad" merge, when a lot of work has gone on in the repo based on that merge?

share|improve this question
1  
Could you post a screen shot of the git tree (redacted appropriately) or the output of your favorite git log format with appropriate annotations about what happened at the various commits? (I'd redact/annotate git log --graph --pretty=oneline --abbrev-commit and go from there) –  MichaelT Dec 30 '13 at 4:11
1  
It's too late for you, but unit tests would have caught that. –  nalply Jan 2 at 19:57
    
@nalply: Not if the bad merge also deleted the unit tests. –  Aaronaught Jan 9 at 2:34
    
Wow, that's really insidious bad luck. –  nalply Jan 9 at 9:04

2 Answers 2

If I understood correctly, this is your situation:

    ,-c--c--c--c--M--a--a--X ← develop
o--o--y--y--y--y-´

After some common history (o), you committed and pushed your work (y). Your coworker (c) did work on his local repository and did a bad merge (M). Afterwards there might be some additional commits (a) on top of M.

git reset --hard develop M^2
git branch coworker M^1

Now your graph looks exactly like before the bad merge:

    ,-c--c--c--c ← coworker
o--o--y--y--y--y ← develop

Do a good merge (G):

git checkout develop
git merge coworker

Resulting in:

    ,-c--c--c--c-、
o--o--y--y--y--y--G ← develop

Now transplant the additional commits:

git reset --hard X
git rebase --onto G M develop

This gives the final result:

    ,-c--c--c--c-、
o--o--y--y--y--y--G--a--a--X ← develop

Be aware that this might result in more merge conflicts. Also you just changed history, i.e. all your coworkers should clone/reset/rebase to the new history.

PS: of course you should replace G, M and X in your commands by the corresponding commit id.

share|improve this answer
    
It seems fairly evident in the question that all of these commits have already been pushed to a shared repository, so I don't think rebasing is a good choice. Reverting all the recent commits and then cherry-picking the reverted non-conflicting ones on top of the good merge is safer. –  Aaronaught Jan 9 at 2:34
    
That was the part with the clone/reset/rebase. - If there are only a few developers, telling them to update their repositories might be a valid option. –  michas Jan 9 at 2:38

It's good that you're thinking about how to fix the repository, but if your coworker only deleted new files and didn't overwrite a lot of updates, then a much simpler approach would be to simply restore the files that were deleted.

I'd probably start by trying to just cherry-pick (onto the current head) the original commits in which you added the code that has now gone missing. If for whatever reason that doesn't work, just check out the old revision with the files you added, and re-add them in a new commit.

What you describe is actually a subset of a well-known Git anti-pattern, which for the life of me I cannot remember the name of - but the gist of it is, making any "manual edits" during a Git merge (i.e. edits that aren't actually resolving any merge conflicts but are making some totally unrelated change) is considered an extremely bad practice because they are essentially masked by the merge itself, and are easily overlooked in code reviews or debugging sessions.

So definitely explain to your coworker that this was an epic fail, but consider slapping on a band-aid before prepping for major surgery.

share|improve this answer
    
I agree, if it is whole entire files that are gone one thing you can do is this if you don't care about history in the old files: 1.make a new branch from the currently messed up branch. 2.switch back to the bad branch and make another new branch that is your rescue branch 3. From your rescue branch go back to the commit before the fail commit. 4. Copy the deleted files somewhere outside of git 5. Switch to the other new branch. 6. Copy the new versions of the deleted files to the new branch and commit. There's a more complicated way that saves history that is a famous post by Linus T. –  Elin Jan 9 at 3:03
    
Actually this shows how you can use checkout jasonrudolph.com/blog/2009/02/25/… That's much nicer. –  Elin Jan 9 at 4:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.