Re: Merging emacs-23 into trunk

[Óscar Fuentes]

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
cherry-picking).

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.