0

Consider the following situation.

I have two branches: main and main_feature_#1.

  1. I created a pull request and merged main_feature_#1 into main. I found some issue with the merge and there was no way out — had to revert this merge; did this locally and pushed it.
  2. Checkout out main_feature_#1 and reverted one of the commits.

Now when I open a pull request for main vs main_feature_#, the only commit that is shown is the last revert made on main_feature_#. Local merge from main_feature_#1 into main also shows the same thing. git diff main main_feature_#1 shows all the changes though.

However, a pull request for main_feature_#1 vs main shows all the differences for a proper merge.

I don't know what to do anymore. :(

p0lAris
  • 4,750
  • 8
  • 45
  • 80
  • Did you revert the revert first? – Makoto Dec 03 '15 at 19:37
  • You mean I have to revert the revert I made on `main`? And Why? – p0lAris Dec 03 '15 at 19:38
  • Or are you technically saying that I should have never reverted the merge in the first place. Just reverted something in `main_feature_#1` and then opened a new pull request. – p0lAris Dec 03 '15 at 19:39
  • 1
    `main_feature_#1` is a terrible name for a git identifier. The `#` character is the comment character in Unix shells, so to use the identifier correctly in Unix command lines, you will always have to be quoting the # character or the entire identifier. – Kaz Dec 03 '15 at 19:42
  • I never need to do that on the Mac; and this is the convention my workplace follows; sorry about this! – p0lAris Dec 03 '15 at 19:44
  • 1
    [Here's a reference to what I'm talking about.](http://stackoverflow.com/questions/1078146/re-doing-a-reverted-merge-in-git) It sounds like your scenario is identical (and all of the changes from `main_feature#1` *would* be present on your branch; it just so happens that a later commit came in and reversed their additions. It's not as if the merge never happened.) – Makoto Dec 03 '15 at 19:49
  • Thanks very much. Can you please post the same thing in an answer; would like to accept. Thanks again! – p0lAris Dec 03 '15 at 19:59
  • If the duplicate answer helped you out, feel free to close this as a dupe of that. I wouldn't want to repeat information that's already out there. – Makoto Dec 03 '15 at 20:12

1 Answers1

0

This is a common issue with merge reverts. There are several ways to fix it. The easiest is to use git cherry-pick to reapply those commits anew, but can be tedious on a longer branch history. I usually do rebase with all three params git rebase --onto main_feature_#1 <start of the main_feature_#1> <first commit before the unwanted merge> --interactive.

Mykola Gurov
  • 8,517
  • 4
  • 29
  • 27