4

I have a history like this:

A - B - M
 \    /
    C

A, B and M are master, C is on a feature branch.

I made two mistakes:

  1. I didn't realize that the company remote doesn't accept merge commits before I made it.
  2. I changed a lot of things in the Merge commit apart from simply resolving the conflict.

I wanted to rebase, so it would look like A - B - C - M, C - M probably squashed together.

I only found one question on the internet which actually looked quite similar to my case, the only response was "merge is fine".

I admit I'm still not 100% familiar with the rebase syntax, but any combination I told git to rebase, with or without -p and/or -i, it either said there is nothing to rebase (noop) or said it's not working.

What seemed to be the logical choice is to step on C and rebase -ip master, but it didn't quite do what I expected it would.

Community
  • 1
  • 1
Martin S.
  • 43
  • 1
  • 6

1 Answers1

2

Given this history:

A - B - M
  \    /
    C

At M, of you soft reset to B, and commit, then you will end up with A - B - M' which seems to be what you want:

git checkout M
git reset B
git commit

The content of the branch will remain the same, none of these commands change that, only C gets eliminated from the history, making it look like a straight branch.

janos
  • 120,954
  • 29
  • 226
  • 236
  • That would be `git checkout ` and `git reset --soft B`, as the new commit is made from the contents of the index, and affects the current branch (or detached HEAD). – torek Nov 25 '16 at 23:44
  • This is working like a charm, but I have no idea why. Why does reset do this? M is gone (resetting tends to do that I guess), C is there on the separate branch but nobody cares about _him_. So resetting soft is basically makes the branch head point to that commit and puts the diff as change to be committed. That is nice to know, especially that it doesn't care about branches or anything, only actual changes? – Martin S. Nov 28 '16 at 16:32
  • When you do a soft reset, the content of your working directory doesn't change. This is crucial. But HEAD points to some version that you specified. At that point, looking at `git diff`, you will see differences between HEAD, and your content. And when you commit, naturally, these differences become the content of the new commit. It's pretty simple. And yeah, I think it can be said that Git cares mostly about *actual changes* in general. It makes a lot of sense. – janos Nov 28 '16 at 16:42