git-merge oddities (or: how to create a one-parent merge)

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"?