Op 20-3-2012 20:35, Richard Heck schreef:
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.
* First, I'm not sure what you mean by "the merge is empty". Indeed,
'git show 9236a938' does not show any changes in the code, but that's
normal. A merge only combines two sets of commits; the actual changes to
the code is done in the commits themselves. In this case in commit
0a0a837b and in commits 8be18455..758d0482. (try: 'gitk
8be18455..758d0482' this will show all commits that are in this range).
If you want to see the code changes introduced by a merge you can do:
$ git diff 9236a938 9236a938^1
This will show you that the merge is not empty at all.
* Second, what do you mean with "two branches are completely
synchronized" ? I guess you mean that if one branch is based on top the
other they are synchronized ? And if they are 'synchronized', you get a
fast-forward merge and thus no merge commit. This really is a special
case and technically not even a merge.
So whether I get the empty commit depends upon which branch I rebased
against, not what's actually in that branch.
If you rebase a branch A against another branch B, all commits of the
branch B are actually included in branch A. So please don't rebase a
branch A versus another branch B before merging it with branch C,
because than branch B will also be merged into branch C.
If you would have rebased your feature branch against the 2.0.x branch
before merging it into master, you are bound to run into problems if the
commits in the 2.0.x branch are not _exactly_ the same as those in the
master branch.
Vincent
