[Top][All Lists]

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

Re: Merging emacs-23 into trunk

From: Óscar Fuentes
Subject: Re: Merging emacs-23 into trunk
Date: Thu, 11 Nov 2010 21:20:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>>> You are cherry-picking here; cherry-picking is explicitly not tracked
>>>> in the history DAG.
>>> Actually, I'm not cherry-picking: Since all changes until A have been
>>> merged, merging A..B will end up with all changes until B: I'm not
>>> picking some changes and avoiding others.
>>> And indeed
>>> bzr merge -r A..B
>>> will correctly track the history in the case where A has already been
>>> merged and committed.
>> No. It will keep the order of the commits, but that's is all it does as
>> far as the VC history is concerned.
> I have no idea what you mean by the above, but I have tried and tested
>   bzr merge -r A..B
> and in all my tests, in the case where A has already been merged into
> the current tree, it behaves exactly like
>   bzr merge -r B
> with respect to history-tracking.

Yes, when A (or its parent) already is on the target branch with the
same revision-id as it has on the source branch.

But if you cherry-picked A (instead of merging it) you will end with two
instances of the commit that corresponds to A in the VC history: one
corresponds to the cherry-pick and another to the merge. (It is
unfortunate that `bzr merge' is used for merging history and for

Another case is when the parent of A is not on the target branch (with
the same revision-id it has on the source branch.) Then you are
cherry-picking a series of commits.

reply via email to

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