1

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. :(

Improve this question
8
  • Did you revert the revert first? Commented Dec 3, 2015 at 19:37
  • You mean I have to revert the revert I made on main? And Why? Commented Dec 3, 2015 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. Commented Dec 3, 2015 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. Commented Dec 3, 2015 at 19:42
  • 1
    Here's a reference to what I'm talking about. 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.) Commented Dec 3, 2015 at 19:49

1 Answer 1

Reset to default
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.

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

3 Comments

This would make more of a mess of things.
@Makoto not if branch was simple. Otherwise you can always reset back.
Please see @Makoto's answer in the comments. It's pretty much close to perfect and it's very clean.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.