← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/cherry-picking.txt

  • Committer: Martin Pool
  • Date: 2005-06-06 13:24:18 UTC
  • Revision ID: mbp@sourcefrog.net-20050606132418-1082c87e2473e266
- manpage generator by Hans Ulrich Niedermann

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/cherry-picking.txt
 
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