|
6
by mbp at sourcefrog
import all docs from arch |
1 |
************** |
2 |
Cherry picking |
|
3 |
************** |
|
4 |
||
5 |
Bazaar-NG allows you to try to 'cherry pick' changes from one branch |
|
6 |
to another. That is to say that you can merge across only the changes |
|
7 |
from a particular commit, without getting anything else from that |
|
8 |
branch. |
|
9 |
||
10 |
However, because of dependencies in the source, it's not always very |
|
11 |
practical to pick changes out of a widely-diverged branch. The |
|
12 |
general principle is that it's easier to keep things separate and |
|
13 |
combine them later than to mix things up and try to separate them. |
|
14 |
||
15 |
Therefore, we suggest using branches for each line of development that |
|
16 |
might want to separately merge. Create a branch for each major |
|
17 |
feature; create branches for code that is ready to go upstream and for |
|
18 |
code that is very experimental. Branches are cheap. As changes pass |
|
19 |
through these branches they accumulate interesting metadata. |
|
20 |
||
21 |
Design |
|
22 |
------ |
|
23 |
||
24 |
There is little that a tool can do to help with merges once you start |
|
25 |
cherry-picking changes; we need to rely on the merge tool detecting |
|
26 |
that some changes have already been applied. |
|
27 |
||
28 |
We should note that the changes have already come across, but I don't |
|
29 |
see many places where that will be terribly helpful. |
|
30 |
||
31 |
Sometimes a succession of cherry picks will be equivalent to merging |
|
32 |
the whole history up to some point, in which case we can fall back to |
|
33 |
a proper merge. |
|
34 |
||
35 |
When choosing a merge ancestor I think knowing non-contiguous |
|
36 |
cherry-picked changes will not help. |
|
37 |
||
38 |
Cherry-picking is equivalent to putting the merge ancestor just before |
|
39 |
the changeset(s) to be picked in. So we can do this regardless of |
|
40 |
whether we have the whole history of the tree. |
|
41 |
||
42 |