16

I was working on my feature branch and after review, merged it into development to be deployed. Later, a coworker decided to do a release and merged his and mine into master. While deploying he realized his code was buggy and reverted master.

In our fork-and-pull flow, that means that now development and master are both reverted.

When I came in this morning, I rebased from development per usual, to learn afterward there had been a revert.

Now I'm trying to cherry-pick my work from the original feature branch only to realize it gives me "empty commit messages" because of the revert.

  1. is this because revert is a mirror image of my previous commits?
  2. is there a way to revert the revert? (makes my head hurt)
  3. is there anyway to get my commits to show up in the diff now that my I have rebased

Any help is greatly appreciated.

Gina
  • 570
  • 2
  • 5
  • 20
  • Will you show the results of `git log --graph --decorate --oneline --branches --simplify-by-decoration` going far enough back to encompass the relevant commits and show where in that structure the commits you're interested in would be found, please? The easiest way to show the interesting ones is to e.g. `git tag 3a4ca33 so/the-revert`, then it'll show up directly on the log. – jthill May 15 '14 at 15:32

2 Answers2

29

Cherry-pick and rebase checks the patch id of the commit (basically a hash of the change) and already sees that the change exists on the branch, so it doesn't pick it. Rebasing can sometimes work because changes in the files may have caused the actual diff to change a bit--resulting in a different patch id--but that doesn't appear to be the case for you.

You can "revert the revert", though that will re-introduce the broken bits your co-worker introduced. Then you need to revert the buggy commits your co-worker made. It's a lot of reverting, and quite a bit to keep straight, so take it slow and have someone sit with you just to make sure you don't miss anything.

Another choice might be to replay your commits by doing git show COMMIT_ID | git apply. This re-applies the diff to your working tree. As long as your tree is clean, you can use git commit -C COMMIT_ID to re-use the message from the original commit. You can probably use git format-patch and git am to avoid the extra steps.

John Szakmeister
  • 44,691
  • 9
  • 89
  • 79
2

Use an interactive rebase to edit the first commit you want to keep git rebase -i myfirstcommitid^. Apply an amend commit. This should change the hash. Complete the rebase using git rebase --continue all the commits should now have new ids which should allow you to cherry-pick at your leisure.

Immortal Blue
  • 1,691
  • 13
  • 27