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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
