Rev 5554: (mbp) Clarify the description of merge's "--revision" option. in file:///home/pqm/archives/thelove/bzr/%2Btrunk/

[Canonical.com Patch Queue Manager]

At file:///home/pqm/archives/thelove/bzr/%2Btrunk/

------------------------------------------------------------
revno: 5554 [merge]
revision-id: pqm at pqm.ubuntu.com-20101130054940-74uuru7wuvgla2oz
parent: pqm at pqm.ubuntu.com-20101129012353-9fn17vlqdmipx4a9
parent: pub08 at davor.org-20101130044942-wcfcu28h9yz5h0gk
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Tue 2010-11-30 05:49:40 +0000
message:
  (mbp) Clarify the description of merge's "--revision" option.
   Plus a drive-by fix. (Eric Siegerman)
modified:
  bzrlib/builtins.py             builtins.py-20050830033751-fc01482b9ca23183
=== modified file 'bzrlib/builtins.py'
--- a/bzrlib/builtins.py	2010-11-18 00:22:24 +0000
+++ b/bzrlib/builtins.py	2010-11-30 05:49:40 +0000
@@ -3749,16 +3749,20 @@
     with bzr send. If neither is specified, the default is the upstream branch
     or the branch most recently merged using --remember.
 
-    When merging a branch, by default the tip will be merged. To pick a different
-    revision, pass --revision. If you specify two values, the first will be used as
-    BASE and the second one as OTHER. Merging individual revisions, or a subset of
-    available revisions, like this is commonly referred to as "cherrypicking".
-
-    Revision numbers are always relative to the branch being merged.
-
-    By default, bzr will try to merge in all new work from the other
-    branch, automatically determining an appropriate base.  If this
-    fails, you may need to give an explicit base.
+    When merging from a branch, by default bzr will try to merge in all new
+    work from the other branch, automatically determining an appropriate base
+    revision.  If this fails, you may need to give an explicit base.
+
+    To pick a different ending revision, pass "--revision OTHER".  bzr will
+    try to merge in all new work up to and including revision OTHER.
+
+    If you specify two values, "--revision BASE..OTHER", only revisions BASE
+    through OTHER, excluding BASE but including OTHER, will be merged.  If this
+    causes some revisions to be skipped, i.e. if the destination branch does
+    not already contain revision BASE, such a merge is commonly referred to as
+    a "cherrypick".
+
+    Revision numbers are always relative to the source branch.
 
     Merge will do its best to combine the changes in two branches, but there
     are some kinds of problems only a human can fix.  When it encounters those,
@@ -3788,7 +3792,7 @@
     you to apply each diff hunk and file change, similar to "shelve".
 
     :Examples:
-        To merge the latest revision from bzr.dev::
+        To merge all new revisions from bzr.dev::
 
             bzr merge ../bzr.dev