Re: Merging emacs-23 into trunk

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> bzr merge -r A
>> bzr merge --force -r A..B
>> 
>> While I do expect the two to behave differently w.r.t conflicts (or in
>> the case where A>B, say), I think the fact that the second does not
>> register the revisions from A to B in the "pending merges" data seems
>> like a bug to me.

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

> Why is that a problem, in the context of this discussion (merging from
> a release branch to the trunk)?

Because, in order to cherry-pick, I merge the various parts of the
emacs-23 branch differently, so I need to issue various "bzr merge"
commands to merge the branch bit by bit.

I could work around this limitation by working on a separate temporary
branch (where I can commit after each "bzr merge") and then merge that
temporary branch into trunk.

>> And the fact that
>> bzr merge -r A
>> bzr merge --force -r B
>> applies the A changes twice is another bug.

> I think this is again because cherry-picking is not tracked, so bzr
> doesn't "know" A is already there.  In a nutshell, when you
> cherry-pick, you need to do your own bookkeeping.

Where do you see cherry-picking in the above commands: the -r argument
always specifies just a revision on the branch, not a "A..B".


        Stefan