-1

I don't want to duplicate, but I don't see any questions/answers that exactly fit my situation.

So our team has to work with another team. I thought I was supposed to merge a feature branch of theirs into our release branch. Turns out it wasn't the right one. I reverted the merge commit. I found out that files added in the merge from their feature branch can't be added back when I tried to pull from their other branch they want me to use. I reverted the revert. I then manually "put back" all the changes that had happened in that first merge commit that I reverted and reverted again. Now I still can't pull from the branch they want me to pull from.

Which strategy would be the best to use at this point?

Many branches, both sides, are being used by other team members, so my release branch being "broken" (the other team can't add their files back) is a big problem.

enter image description here

Improve this question
14
  • 1
    I think a little example with simple ascii branches would help us understand what is going on. Commented Jul 14, 2021 at 16:30
  • 1
    What do you mean by "files added in the merge can't be added back"? Commented Jul 14, 2021 at 16:31
  • Just in case: The correct branch that you had to merge includes revisions that were in the wrong branch that you merged/reverted before? If that is the case, git won't like it and getting around this might be a little troublesome. You might have to create separate clones of the branches so that git does not see that as revisions already merged in.... or you might have to rewrite your branch so that you get rid of the whole wrong merge altogether. Commented Jul 14, 2021 at 16:32
  • @eftshift0 like do a reset to the commit just before i did the merge of the wrong branch? Commented Jul 14, 2021 at 16:36
  • Yeah.... rewriting history is always a resource.... only a painful one if other people are already using the branch. But if you decided to to a git reset --hard, it is like it never happened in the first place. If it is a private branch (as in it hasn't been pushed, you are the only one who is using it locally, for example), do not think twice and reset it. Commented Jul 14, 2021 at 16:36

1 Answer 1

Reset to default
0

If I understood correctly from the question and follow-ups in the comments, you merged a branch, reverted it and now you want to merge a different branch that includes some revisions that were reverted as parts of the wrong branch, right?

Rewriting is not a viable path because other people are already using the wrong merge/reversion.

If that is the case, I think the next best-thing you can do to make git allow you to merge that branch is to rewrite history (privately) of the correct branch so that to git those are really new revisions. So, find the last common ancestor between your branch before the bad merge and the good branch you want to merge. That can be done with git merge-base revision-before-bad-merge the-right-branch. Let's call this revision X

git checkout X git cherry-pick X..the-good-branch #I am assuming it's a straight line

Now, you have a private clone of the right branch that is made up of completely unmerged revisions to git. If you tried to merge this revision into the target branch, it should be fine:

git checkout target-branch git merge HEAD@{1} -m "Merging a clone of branch whatever because I busted it merging the wrong branch before.... sorry"

Git should allow you to do that. As a warning: do that locally to see how it goes.

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

2 Comments

reading this over now, but i just added a visual, if it helps.
I have corrected the recipe. Make sure that my assumptions (first 2 paragraphs) are correct so that then the recipe is appropriate for your situation.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.