emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange response after merge from upstream


From: Óscar Fuentes
Subject: Re: Strange response after merge from upstream
Date: Wed, 02 Dec 2009 08:05:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]