~bzr-pqm/bzr/bzr.dev

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
**************
Cherry picking
**************

Bazaar-NG allows you to try to 'cherry pick' changes from one branch
to another.  That is to say that you can merge across only the changes
from a particular commit, without getting anything else from that
branch.

However, because of dependencies in the source, it's not always very
practical to pick changes out of a widely-diverged branch.  The
general principle is that it's easier to keep things separate and
combine them later than to mix things up and try to separate them.

Therefore, we suggest using branches for each line of development that
might want to separately merge.  Create a branch for each major
feature; create branches for code that is ready to go upstream and for
code that is very experimental.  Branches are cheap.  As changes pass
through these branches they accumulate interesting metadata.

Design
------

There is little that a tool can do to help with merges once you start
cherry-picking changes; we need to rely on the merge tool detecting
that some changes have already been applied.

We should note that the changes have already come across, but I don't
see many places where that will be terribly helpful.

Sometimes a succession of cherry picks will be equivalent to merging
the whole history up to some point, in which case we can fall back to
a proper merge.

When choosing a merge ancestor I think knowing non-contiguous
cherry-picked changes will not help.

Cherry-picking is equivalent to putting the merge ancestor just before
the changeset(s) to be picked in.  So we can do this regardless of
whether we have the whole history of the tree.