Home / Questions / 151133
Accepted
Norak
Asked: 2020-03-29 01:49:50 +0800 CST 2020-03-29 01:49:50 +0800 CST

Can't merge branch again with git after dropping commit

  • 772

I made a mergebranch to master and later I realized that this branch had changes that I didn't want.

I've uncommitted that one mergewith:

git revert -m 1 commit_hash

Now I need to merge that branch back to master and it won't let me. It looks like it's already merged, but the changes don't show up in master. It tells me the message: " Already up-to-date." when trying to merge again.

Does anyone know what's going on? How can I merge that branch again?

edit:

  • In the master branch, after this some more commits have been made
  • In my branch (in which I have the problem when merging) no commit or new change has been made
git

1 Answers

  1. Best Answer

    The revertone for a merge is confusing, because it doesn't do exactly what you think.

    If you have this story:

                     H
--o--o--o--M--o--o
          /
   ---A--B

    Where His HEAD (let's say for example from the master branch) and Mis the commit in which you merged, and in that situation you do a git revert -m1 M, the merge is not undone as if it had never been done, but a new commit is added to the branch master, but a commit whose changes are the opposite of what you put in M. let's call himW

                        H
--o--o--o--M--o--o--W
          /
   ---A--B

    That is, if, for example, as a result of the merge Ma file has a couple of lines added, as a result of the revert Wthat couple of lines will be deleted.

    In other words, the commit W introduces changes in your history, but they are changes such that all your files are left in an identical state to the one they had in the commit before M, plus the changes introduced by commits after M. Equivalent to manually editing those files yourself, correcting the changes that had been introduced in the merge, and then making one addand one commitof those modifications. The files change, but the history of the graph does not change, where we can see that the merge is still there (and therefore you cannot do it again).

    Depending on what has happened from the point I show in the figure above (have you continued committing to the master branch? Have you continued committing to the branch where Ay were B?) the solution to fix the mess may be different.

    You can read more details (from Linus Torwalds himself) here: How to revert a faulty merge (from where I "plagiarized" the figures). Or edit your question to add extra information that allows me to help you.

    Update

    The user confirms that the original branch ( ---A--Bin the figure) has not had changes, but the master branch has. The current situation I understand would be something like this:

                              H
--o--o--o--M--o--o--W--x--x
          /
   ---A--B

    where xwould be the new commits in master.

    Presumably these xhave somehow fixed the problem that prevented the merge in from Mbeing invalid, so we want to do that merge again, but we can't because it's already done.

    One solution is to revert the commit that the revert had done . It may sound like a tongue twister, but the idea is:

    git revert W

    and the thing would be now:

                                 H
--o--o--o--M--o--o--W--x--x--N
          /
   ---A--B

    So the changes introduced by the commit Ware applied "reverse" in the commit N. So, following the example above, if the merge Mhad caused two new lines in a file, the first revert Wto the file would delete those two lines and this new revert( N) will add those two lines back to the file.

    Naturally this can cause a conflict if the "restored" files in Whave been modified in an incompatible way in one of the x, but this is something that is solved in the known way (the conflicting files are edited, they are added with git addand the revert is completed with git commit)

    • 4