Re: Strange response after merge from upstream

[Eli Zaretskii <eliz@gnu.org>]

> From: Alexander Belchenko <bialix@ukr.net>
> Date: Wed, 02 Dec 2009 00:23:46 +0200
> 
> Eli Zaretskii пишет:
> > I created a repository with a trunk/ and quickfixes/ branches in it,
> > just like the wiki says.  I waited a day without making any
> > modifications in quickfixes/ (it looks like the bzr repository is only
> > updated once a day), and then did a "bzr pull" in trunk/ and "bzr
> > merge; bzr commit" in quickfixes/.  Strangely, "bzr missing" after
> > that in quickfixes/ says I "have 1 extra revision(s)" and shows all
> > the files merged from the trunk.  Is that expected? it surprised me,
> > because I thought the result would be a branch that is an exact copy
> > of the trunk, and thus has no "extra revision(s)".
> 
> Yes, after merge you did commit, therefore you have 1 extra revision (just committed).

I understand that, but that commit was because merge by itself does
not commit the changes I pulled from the mainline.  Without the
commit, bzr was even less happy.

I guess I expected to see nothing from "missing" after these
operations, since really the branch is an exact copy of the upstream.
Evidently, that's not "missing"'s logic and purpose.  "bzr diff" did
come up empty-handed, as expected.

> You may want to use `bzr merge --pull` to get equivalent of git fast-forward merge.
> merge --pull will pull new changes from other branch if possible, thus make your branch a copy of
> the other branch. Or it will do merge when 2 branches are diverged, i.e. both branches has new
> commits, not present in other branch.

I don't know git.  How is "merge --pull" different from merge followed
by commit? would it avoid the "1 extra revision" in the output of
"missing"?