0

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:

enter image description here

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?

Community
  • 1
  • 1
Charles
  • 4,372
  • 9
  • 41
  • 80
  • Are you looking to rewrite your history? – Tim Biegeleisen May 06 '16 at 00:45
  • Kind of? If removing the empty commit could allow me to properly merge, I suppose that would be a solution. – Charles May 06 '16 at 00:49
  • Do you realize that the diagram (and the bash) indicate that the purple branch has already been merged into the teal branch? – Tim Biegeleisen May 06 '16 at 00:54
  • Yes, but as I was saying in my post, it is actually an empty merge. It occurred when I switched the master branch through the instructions in the linked SO question. – Charles May 06 '16 at 00:55
  • What is an "empty" merge? – Tim Biegeleisen May 06 '16 at 01:05
  • It shows as a merge of the purple branch into the teal branch, but there are actually no changes reflected in the teal branch. Now, I'm trying to *actually* do the merge, after previously having an "empty" merge. – Charles May 06 '16 at 01:09

1 Answers1

0

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.

Schwern
  • 153,029
  • 25
  • 195
  • 336