Git merge "Already up to date" but not

Question

I messed up a bit. I am working on a project, It has many different branches. I merged branch A to master, there was some conflict. I messed up here, I did not look into the conflict properly and removed the arrows and then commit then push into master. But It the current master branch does not have the changes I have made on the Branch A. I tried again to merge branch A into master again, but it says "Already upto date".

How do I merge into master again ?

Answer 1

What you have is something like

x --- x --- x --- M <--(master)
 \               /
   x --- x --- B <--(branch)

Because M has B as one of its parents, any attempt to merge B to M (or master which is at M, or any commit that can reach M via chain of parents) will say "already up to date" because it believes M is telling how to account for the changes in B. So you need to first undo M.

If you've pushed to a remote that is shared with other developers, this is going to cause a headache. See "Recovering from upstream rebase" in the git rebase documentation; even though we're not going to do any rebases, the same situation applies because we're replacing history.

Anyway, here's how, assuming nothing has been added to master since the merge:

git checkout master
git reset --hard master^

Now M is no longer reachable by master, so you can repeat the merge to properly resolve conflicts.

git merge branch

Now you'll have

                    M
                   /
x --- x --- x --- M' <--(master)
 \               /
   x --- x --- B <--(branch)

Note that M still exists (though you won't see it by default), and the new merge has a new ID (so I've noted it as M'). Because of this, if you push to a remote (that had already had M pushed to it), you have to do

git push -f

and at this point anyone else using the repository must recover, because you've effectively inflicted an upstream rebase on them.

And if other work had been committed to master after the merge?

x --- x --- x --- M --- A --- R --- G <--(master)
 \               /
   x --- x --- B <--(branch)

Well, it can still be done, but with more potential trouble.

git branch new_master M^
git checkout new_master
git merge branch

resolve conflicts, and you have

              ------------------------- M --- A --- R --- G <--(master)
             /                         /
x --- x --- x --- M` <--(new_master)  /
 \               /                   /
   x --- x --- B --------------------
               |
            (branch)

So now

git rebase --onto new_master M master

which potentially will have conflicts due to A, R, and G having originally been applied to a different work tree. If you can sort it out, you then

git branch -d new_master

resulting in

x --- x --- x --- M' --- A' --- R' --- G' <--(master)
 \               /
   x --- x --- B <--(branch)

Again the old M, A, R, and G commits still exist (and in fact if you'd previously pushed, origin/master refers to them; so again push -f would be necessary) - but I've removed them from this last diagram because it would get messy.