[Top][All Lists]

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

Re: Merging emacs-23 into trunk

From: Stefan Monnier
Subject: Re: Merging emacs-23 into trunk
Date: Wed, 10 Nov 2010 14:03:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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


reply via email to

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