Re: Strange response after merge from upstream

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

> 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.

On one branch you used `pull', which adds revisions on top of those you
previously had. So if you pulled 10 revisions, you have 10 more
revisions on the history of that branch.

On the other branch you merged the missing revisions and then you had to
commit the merge after resolving conflicts, if any. You end with 10
revisions coming from the parent branch plus one revision from your
commit totalling 11. If the source tree ends being indentical on both
cases, it is just by chance. Nothing prevents you from editing the files
before the post-merge commit.

The key here is that the final history of those branches allows them to
contain different working files, i.e. you can't guarantee that the
branches have not diverged looking at the set of revisions they contain
and how they arranged on its DAG. One branch has a revision that is
unknown by the other.

As you probably already know, each revision has a revision-id that makes
it unique and is used for checking its existence on a branch, no matter
if it was originated there or arrived via pull or merge. That two
branches ends containing the same source code is irrelevant if the
revisions they contain and their arrangement on the respective DAGs
makes the branches non-equivalent.

>> 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?

merge -pull does this:

if branches-diverged?
  yes: merge  (you need to explicitly commit afterwards)
  no : pull   (no need to commit)

> would it avoid the "1 extra revision" in the output of "missing"?

Yes, because your quickfixes/ branch did not diverged from the branch
you pulled from, so it will do a `pull', like you did on your trunk
branch.

-- 
Óscar