1

I have a feature branch, let's call it A, and a main line, let's call it B, where we deliver. The problem is the following:

  1. Branch A was many commits ahead of branch B, nothing extraordinary so far. So I did a merge from branch A to B.
  2. Then I noticed, this is not what I wanted as I suspect the automatic merges were not alright.
  3. I did a revert for the merge, which was ok, the changes merged disappeared.
  4. I only want to have the code state of branch A in branch B; consequently, I removed the directories and files locally in branch B and wanted to do the merge from branch A again, which does not work anymore as git perceives that the merge has already been done. My second idea is to check out branch A in branch B but I don't know how as normal checkouts from the remote repository will go into the corresponding branches: A in A and B in B.

Any idea how I could check out branch A in branch B? Remark: there are no changes in the main line since starting this feature branch A, so what I need is A in branch B. Thanks for any solutions in advance.

Would git fetch <remote> <remoteBranch>:<localBranch> do this?

git fetch origin A:B
git push origin B

Solution: See the answer from VonC and also my questions about the index. Thanks for all responses.

cd /path/to/repo
git switch B
git restore -s A -SW -- .
git commit -m "override B with A content"
Tamas
  • 736
  • 2
  • 11
  • 27

3 Answers3

2

But I do not want to investigate file by file where an error might be in the content, I would just like to remove the state in B and get the state of A in B. How could I do that?

Keeping your history as is, you can restore A content on your current B

cd /path/to/repo
git switch B
git restore -s A -SW -- .
git commit -m "override B with A content"
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the answer, it solved the issue. I think that now for any branches that had been created before restoring A in B, a normal merge in B will not work due to the index but for any branches that had been created after the restore, the normal merge will work, as it is tracked by the index. Am I right? – Tamas Feb 02 '23 at 17:02
  • 1
    @Tamas True, That should work for branches created after the restore indeed. – VonC Feb 02 '23 at 19:54
1

Let's start by visualizing your situation:

                            branch B
o---o---o---------------M---W
         \             /
          o---o---o---o
                      branch A

I'm going to assume that you have pushed both the merge commit M and its reverse W, so you can no longer rewrite the history of branch B.

Reverting a faulty merge

If you want to bring in the changes from branch A into B after the first merge has been reverted, you have to revert the revert by reverting commit W:

git switch B
git revert W

However, you said that you don't want to create a commit right away, but rather you'd like the changes made in branch A to be in the working directory while you're on B. You can do that by using the --no-commit option of git-revert:

git switch B
git revert --no-commit W

This will bring back the changes from branch A into your working directory.

If you're interested in understanding why this situation occurs in the first place, I think Linus himself explains it best:

Reverting a regular commit just effectively undoes what that commit did, and is fairly straightforward. But reverting a merge commit also undoes the data that the commit changed, but it does absolutely nothing to the effects on history that the merge had.

So the merge will still exist, and it will still be seen as joining the two branches together, and future merges will see that merge as the last shared state - and the revert that reverted the merge brought in will not affect that at all.

So a "revert" undoes the data changes, but it's very much not an "undo" in the sense that it doesn't undo the effects of a commit on the repository history.

So if you think of "revert" as "undo", then you're going to always miss this part of reverts. Yes, it undoes the data, but no, it doesn't undo history.

Enrico Campidoglio
  • 56,676
  • 12
  • 126
  • 154
  • Thanks for the response and the graphical representation! Actually, I have already reverted the revert before your post without the "--no-commit" option. But I do not want to investigate file by file where an error might be in the content, I would just like to remove the state in B and get the state of A in B. How could I do that? – Tamas Dec 19 '22 at 10:27
  • Are you able to rewrite the history in `B`? If so, you can just remove the merge commit `M` and its reverse `W` with `git reset --hard M^`. Then, you can do a [_squash merge_](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---squash) with `git merge --squash B`. – Enrico Campidoglio Dec 19 '22 at 15:10
1

You can trick git into thinking that the merged branch was not merged by just rewriting its history

git checkout $( git-merge-base feature-branch upstream-branch-before-the-merge )
git cherry-pick HEAD..feature-branch # assuming it is a straight line
# now you have a history just like the original branch but, to git, this is not merged
# let's set the pointer over here
git branch -f feature-branch

If you try to merge the new branch, git should be fine with it.

eftshift0
  • 26,375
  • 3
  • 36
  • 60