Re: Strange response after merge from upstream

["Óscar Fuentes" <ofv@wanadoo.es>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Eli Zaretskii writes:
>
>  > How is "merge --pull" different from merge followed by commit? 
>  > would it avoid the "1 extra revision" in the output of "missing"?
>
> Maybe.
>
> - "bzr merge" always merges, and you must commit.

Correct.

> - "bzr pull" does a trivial merge and commit if your local branch's
>   tip revision is an ancestor of the remote revision, otherwise it
>   aborts without changing anything.  (A successful pull is also called
>   a "fast forward".)

`pull' never merges because there is nothing that can cause
conflicts. The scenario where `pull' works is this:

my_mirror:  A B C D

upstream :  A B C D E F

After pull:

my_mirror:  A B C D E F

upstream :  A B C D E F

It is impossible to get a conflict here. It just adds the revisions to
the DAG. However, if you have something like this:

my_branch:  A B C D X

upstream :  A B C D E F

conflicts may arise and you must merge to obtain

my_branch:  A-B-C-D-X------M
                   \--E-F-/

upstream :  A B C D E F

M is the commit you make after the merge, aka the "merge point".

Even if the branches didn't diverged, a `merge' creates a different
graph than a `pull'. This is the state before the operations:

upstream :  A B C D E F

my_pull  :  A B C D

my_merge :  A B C D

This is after:

upstream :  A B C D E F

my_pull  :  A B C D E F

my_merge :  A-B-C-D-X------M
                   \--E-F-/

This is most obvious on the output of `bzr log'.

"fast forward" is git lingo.

[snip]

-- 
Óscar