/breezy/unstable

To get this branch, use:
bzr branch https://code.breezy-vcs.org/breezy/unstable

« back to all changes in this revision

Viewing changes to doc/en/user-guide/adv_merging.txt

  • Committer: Jelmer Vernooij
  • Date: 2017-05-24 01:39:33 UTC
  • mfrom: (3815.3776.6)
  • Revision ID: jelmer@jelmer.uk-20170524013933-ir4y4tqtrsiz2ka2
New upstream snapshot.

Show diffs side-by-side

added added

removed removed

Lines of Context:
18
18
To merge only the changes made by revision X in branch ``foo``,
19
19
the command is::
20
20
 
21
 
  bzr merge -c X foo
 
21
  brz merge -c X foo
22
22
 
23
23
To merge only the changes up to revision X in branch ``foo``,
24
24
the command is::
25
25
 
26
 
  bzr merge -r X foo
 
26
  brz merge -r X foo
27
27
 
28
28
To merge only the changes since revision X in branch ``foo``,
29
29
the command is::
30
30
 
31
 
  bzr merge -r X.. foo
 
31
  brz merge -r X.. foo
32
32
 
33
33
To merge only the changes from revision X to revision Y in branch ``foo``,
34
34
the command is::
35
35
 
36
 
  bzr merge -r X..Y foo
 
36
  brz merge -r X..Y foo
37
37
 
38
38
Like a normal merge, you must explicitly commit a cherrypick. You may wish
39
 
to see the changes made using ``bzr diff``, and run your test suite if any,
 
39
to see the changes made using ``brz diff``, and run your test suite if any,
40
40
before doing this.
41
41
 
42
 
Unlike a normal merge, Bazaar does not currently track cherrypicks.
 
42
Unlike a normal merge, Breezy does not currently track cherrypicks.
43
43
In particular, the changes look like a normal commit and the (internal)
44
44
revision history of the changes from the other branch is lost.
45
45
In many cases where they are useful (see above), this is not a major
56
56
making all of the changes that would have been in the merge happen in a single
57
57
commit.  After the merge and before the corresponding commit, you can do::
58
58
 
59
 
  bzr revert --forget-merges
 
59
  brz revert --forget-merges
60
60
 
61
61
to keep the changes in the working tree, but remove the record of the
62
62
revisions where the changes originated.  The next commit would then record
64
64
 
65
65
This is desired by some users to make their history "cleaner", but you should
66
66
be careful that the loss of history does not outweigh the value of cleanliness,
67
 
particularly given Bazaar's capabilities for progressively disclosing merged
 
67
particularly given Breezy's capabilities for progressively disclosing merged
68
68
revisions.  In particular, because this will include the changes from the
69
69
source branch, but without attribution to that branch, it can lead to
70
70
additional conflicts on later merges that involve the same source and
78
78
upper bound in the revision range which is *below* the lower bound.
79
79
For example, to back-out changes made in revision 10, the command is::
80
80
 
81
 
  bzr merge -r 10..9
 
81
  brz merge -r 10..9
82
82
 
83
83
If you want to take most changes, but not all, from somewhere else, you
84
84
may wish to do a normal merge followed by a few reverse cherrypicks.
92
92
working in branch ``foo`` when you meant to work in branch ``bar``:
93
93
 
94
94
1. Change into branch ``bar``.
95
 
2. Run ``bzr merge --uncommitted foo``
96
 
3. Check the changes came across (``bzr diff``)
 
95
2. Run ``brz merge --uncommitted foo``
 
96
3. Check the changes came across (``brz diff``)
97
97
4. Change into branch ``foo``
98
 
5. Run ``bzr revert``.
 
98
5. Run ``brz revert``.
99
99
 
100
100
.. TODO Selective file merging?
101
101
 
105
105
 
106
106
Another option to normal merging is *rebasing*, i.e. making it look like
107
107
the current branch originated from a different point than it did.
108
 
Rebasing is supported in Bazaar by the ``rebase`` command provided by
 
108
Rebasing is supported in Breezy by the ``rebase`` command provided by
109
109
the ``rebase`` plugin.
110
110
 
111
111
The ``rebase`` command takes the location of another branch on which
121
121
 
122
122
Each revision that is replayed may cause conflicts in the tree. If this
123
123
happens the command will stop and allow you to fix them up. Resolve the
124
 
commits as you would for a ``merge``, and then run ``bzr resolve`` to
 
124
commits as you would for a ``merge``, and then run ``brz resolve`` to
125
125
marked them as resolved. Once you have resolved all the conflicts, you
126
 
should run ``bzr rebase-continue`` to continue the rebase operation.
 
126
should run ``brz rebase-continue`` to continue the rebase operation.
127
127
If conflicts are encountered and you decide not to continue,
128
 
you can run ``bzr rebase-abort``. You can also use ``rebase-todo`` to
 
128
you can run ``brz rebase-abort``. You can also use ``rebase-todo`` to
129
129
show the list of commits still to be replayed.
130
130
 
131
131
Note: Some users coming from central VCS tools with poor merge tracking
132
132
like rebasing because it's similar to how they are use to working in older
133
133
tools, or because "perfectly clean" history seems important. Before rebasing
134
 
in Bazaar, think about whether a normal merge is a better choice. In
 
134
in Breezy, think about whether a normal merge is a better choice. In
135
135
particular, rebasing a private branch before sharing it is OK but
136
136
rebasing after sharing a branch with someone else is **strongly** discouraged.