6

I had two branches both independent. I worked on them at various points over a month. I went to merge one branch (let's call it apple) into the other (let's call it orange) by checking out orange and doing git merge --no-ff apple and everything went fine. In gitk I could clearly see the branches each had their own history and it was merged together in a merge commit on orange.

Later I realize that a commit in orange is incorrect, there is a mistake in the build process, and I must edit that early commit on orange. I use git rebase -i HEAD~19, choose the commit and change pick to edit. So I edit the commit and everything is fine, and I finish the rebase. I go back into gitk and all the history of the two branches is one linear history on orange.

So did I screw something up or is this the way it's supposed to be? I used git reflog to go back to when I did the merge, then I did another reset hard to go back to right before the merge on orange, then I did the rebase and fixed that commit, then after that I did the merge. Now everything looks the way I'd expect where the commits from the branches aren't interlaced together.

For future reference can someone tell me how I can rebase commits on a branch where I've merged in another branch, without ending up with interlaced commits (linear history)?

If my terminology isn't correct feel free to edit this. Thanks again

loop
  • 3,460
  • 5
  • 34
  • 57
  • I don't know `gitk` but in `gitg` I have an option to choose branches, did you choose something like All local branches? – Alvin Wong Oct 19 '12 at 02:54
  • Maybe rebase on the commit ID instead of the relative `HEAD~19`? – nneonneo Oct 19 '12 at 03:11
  • 1
    Note that git 1.8.5 will introduce a [neat way to preserve merge on `pull --rebase`](http://stackoverflow.com/a/18756102/6309) – VonC Sep 12 '13 at 05:37
  • @VonC Hi, thanks for the update I appreciate it. I'll keep that in mind if I ever run into the problem again. – loop Sep 13 '13 at 04:50

1 Answers1

9

This is expected behavior of rebase. It effectively re-writes the history of the branch, and that causes it to (default) lose merges and other meta-data, leaving a straight, simplified branch.

You can preserve merges by using

git rebase --preserve-merges

but there are some issues with combining --preserve-merges with --interactive. Tread carefully.

willoller
  • 7,106
  • 1
  • 35
  • 63
  • 1
    Interesting, but seems to have a drawback: http://marc.info/?l=git&m=129382385207873 – VonC Oct 19 '12 at 05:37
  • Yeah that's what I meant about `-i`. `-i` == `--interactive`. I think the issue is that sometimes a re-arranged history can't properly contain the merge history without wrecking data. – willoller Oct 19 '12 at 05:38
  • 1
    I do know what `-i` stands for, and my point was just to mention that, when combined with `--preserve-merge`, it doesn't seem to resolve automatically known conflicts. – VonC Oct 19 '12 at 05:40
  • @VonC Maybe `rerere` is useful in that event? I haven't run into that issue myself, but yeah it looks frustrating. Thanks! – willoller Oct 19 '12 at 17:20
  • 1
    `rerere`? But the test I point to *precisely* activated `rerere`... and he still had to resolve old merges on a `rebase -i -p`. Hence the true frustration. – VonC Oct 19 '12 at 17:48
  • I don't have the test environment set up, so I can't really replicate. If you added a `git rerere` step to the merge would that make a difference? – willoller Oct 19 '12 at 21:19
  • @VonC The merge commit that disappeared did have two conflicts that I had to fix. Does that mean there will be a pitfall for me if I use that command? – loop Oct 20 '12 at 22:42
  • @test I don't think so, but you might have to resolve *again* those two conflicts. – VonC Oct 21 '12 at 05:32
  • @VonC Is there any way to do an edit like I did without rebasing? – loop Oct 21 '12 at 05:50
  • @VonC darn ok thanks. Thanks willoller, I will mark this as correct. – loop Oct 21 '12 at 06:34