6

We recently had an issue with a strange merge that happened from a branch to master where we saw conflicts that should never have been there.

I finally found the root cause of the problem: a "merge commit" that wasn't one. What I mean: from the commit message, it looked exactly like a merge commit:

Merge remote-tracking branch 'origin/master’ into branchName

Conflicts:
     file1
     file2

The problem? This commit only had 1 parent!

So, I'm pretty sure the person who created this commit didn't type all this by hand. It came from a real merge commit at some point.

But how did it end up with only 1 parent? Was it rebased? That's a possibility, since the person who did this has "pull --rebase" set as default. But I can't really reproduce this problem.

Any ideas?

Nicolas C
  • 944
  • 1
  • 10
  • 22
  • 1
    By the way, I checked and this is the only such commit in our repo: git log --all --max-parents=1 --grep="Merge .*branch.* into " – Nicolas C Mar 06 '14 at 08:07
  • 2
    Probably a rebase without merge preserve, yes. (In most cases such merges are trivial/empty and vanish upon rebasing, but this one, with resolved conflicts, was nontrivial.) – torek Mar 06 '14 at 08:14
  • @torek thanks! I'll try to reproduce this with a merge that has conflicts and without the preserve-merges option. – Nicolas C Mar 06 '14 at 08:17
  • [What exactly does git's “rebase --preserve-merges” do (and why?)](http://stackoverflow.com/q/15915430/98057) – André Laszlo Mar 06 '14 at 08:18

0 Answers0