On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:
Op 20-3-2012 0:15, Richard Heck schreef:
This is in my private repo. I have a branch master, and another
branch bugs/7975, and another branch lyx/trunk that is tracking the
main repo, set up as you suggested. The master and lyx/trunk branches
were completely in sync, or so I thought. So then I did:
git checkout lyx/trunk
git merge bugs/7975
and I ended up with the merge commit, representing the new commit
from bugs/7975 as one branch and some of the material from lyx/trunk
as a separate branch. I think was, in part, because bugs/7975 had
been rebased against branch. I've done some other tests, and if I
rebase it against lyx/trunk then of course it is OK.
This is just the classic example of a merge. In one branch is the
development of the others (master) and your development is in your
private branch (bugs/7975). Now you merged the two together.
If you rebase your feature branch on top of master first and then do a
merge, you will get a special type of merge, namely a fast-forward
merge. If you would specify --no-ff, you would still get a merge commit.
I'm not sure what part is surprising to you.
What's surprising is that I get a non-fast-forward merge that is empty.
Unsurprising that it's empty, since the two branches are completely
synchronized, but surprising that the empty merge shows up as a commit.
Note that, as I said, this does not happen if I've rebased against the
other branch. So whether I get the empty commit depends upon which
branch I rebased against, not what's actually in that branch.
Richard
