git merge into master branch after switching the master branch

Question

I'm having an interesting issue with merging. I'm not exactly sure how to explain it, so I hope this graph will give a more clear idea:

Basically, the branch in purple USED to be the master branch, but then I needed to revert back to a previous commit to make different changes. When I wanted to do this, I switched the master branch using the instructions here , but as you can see from the graph, this results in an "empty" merge of the original master to the new master (in teal).

Now, now I actually want to merge the purple commits back into master, both of which sprung from the same original commit. I made some more changes to the purple commit before trying to merge back to master (as shown in the 2nd most recent commit). However, when I try to merge, the option is not given because git thinks that the merge already happened (as the "empty" merge at the bottom of the graph).

How can I actually merge the contents of these two branches?

Answer 1

Let's deal with the two commits separately. First, the most recent one.

You have this. M is the merge, Z is the newest purple commit.

... A - B - M [master]
           /
      ... Z

You want this:

... A - B - Z1 [master]

Checkout B, cherry pick Z on top of it (ie. copy the patch which will become the new commit Z1), declare that the new master.

• git checkout B
• git cherry-pick Z
• git branch -f master

Note that the result is master pointing at Z1 , not Z . Same content, different ID. Git doesn't rewrite history so much as it makes new history. Your repository will actually look like this:

... A - B - Z1 [master]
         \
  ... Z - M

With nothing pointing at M (remember, connections in git go backwards) it will be garbage collected. Then Z will have nothing pointing at it and it will be garbage collected.

---

The second purple commit is trickier. It's so far back in history you probably don't want to mess with it without good reason. Without seeing its ancestors it's hard to know what can be done with it. All you've shown us is this:

...   M2 - D - E ... A - B - Z1 [master]
     /
... Y

Without knowing what's before M2 and Y we can't tell if it's safe to rewrite history, or if the merge should be left alone. It could look like this:

... F - G - H - M2 - D - E ... A - B - Z1 [master]
               /
...   W - X - Y

In which case it's a legit merge and should be left alone. Or it could look like this:

... H - M2 - D - E ... A - B - Z1 [master]
     \ /
      Y

In which case you can eliminate the merge by rebasing master on top of Y.

• git checkout master
• git rebase Y

---

All this depends on what Y and Z are doing. Are they related? Is Z and attempt to fix something in Y? If so it's too late to consider Y its own branch. Once a branch is merged stop treating it like a branch. Y is part of master now, just patch master.