From: Karl Hasselström <kha@treskal.com>
Date: Wed, 04 Jun 2008 12:04:11 GMT
Subject: git-merge oddities (or: how to create a one-parent merge)
Message-ID: <20080604120411.GD2126@diana.vm.bytemark.co.uk>

Consider the following script:

git init
echo foo >> foo
git add foo
git commit -m initial

git checkout -b maint
echo bar >> bar
git add bar
git commit -m "bugfix"

git checkout master
echo foo2 >> foo
git commit -a -m "development"

git checkout -b branch
echo baz >> baz
git add baz
git commit -m "feature"
git merge maint

git checkout master
#git merge maint && git merge branch
#git merge branch && git merge maint
#git merge branch maint

gitk --all

Here we have two branches, "maint" and "branch", that we want to merge
to master. Containment-wise, both master and maint are subsets of
branch:

   o--A           A: master
    \  \          B: maint
     \  \         C: branch
      B--C

If we uncomment the first line, each merge creates a new commit, which
is what we asked for but not what we wanted:

   o--o--o--A
    \  \/  /
     \ /\ /
      B--C

So uncomment the second line instead; now both merges fast-forward,
and all is well.

I thought I could work around the problem of having to merge in the
right order by giving git-merge both branches at once, and having it
realize that a fast-forward will do. And uncommenting the third line,
I indeed see that git-merge has avoided creating a three-parent merge
-- it has correctly realized that maint is a subset of branch.

However, it has also realized that master is a subset of branch, and
skipped that parentage as well. So the resulting merge commit has just
one parent: "branch".

   o--o           A: master
    \  \          B: maint
     \  \         C: branch
      B--C--A

Surely the right thing to do here is to just make it fast-forward to
"branch"?

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle