On Monday, August 27, 2012 5:54:26 PM UTC+2, Michael Haggerty wrote:
> On 08/27/2012 11:30 AM, Fred wrote:
> > I have two remote branches master and branchB.
> > I've merged master into branchB with git checkout branchB && git merge
> > master.
> o---o---o---o <- master
> \ \
> o---o-------O <- branchB
> Merge is not quite a symmetric option. Think of the command "git merge
> master" as "merge the changes from master into the current branch", not
> "merge master and the current branch together". In this case, all of
> the commits from the master branch have been merged into branchB, but
> master is unchanged: it still points at the state of the master branch
> before the merge.
> By contrast, if you had done "git checkout master && git merge branchB",
> the result would be
> o---o---o---o---O <- master
> \ /
> o-----------o <- branchB
> Even though the *contents* of the two merge commits would probably be
> the same , there is a difference of whether master or branchB is
> pointed at the merge commit.
> For example, such a merge could arise in the following scenario: you are
> working on a feature branch separate from master, but it was necessary
> to merge changes from master into the feature branch to continue work on
> the (still unfinished) feature branch. In this situation, you
> definitely do *not* want the merge to cause the changes from branchB to
> be added to master.
Thanks for reply! That's how I understand it too. I've missed the point
however, sha1 for that commit is diffrent in master and branchB.
So commit was in both branches but with diffrent sha1's.
>  Except that the parent of the merge commits would be listed in
> different orders.
> Michael Haggerty
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at