← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/builtins.py

  • Committer: Andrew Bennetts
  • Date: 2010-12-14 23:14:44 UTC
  • mfrom: (5569 +trunk)
  • mto: This revision was merged to the branch mainline in revision 5570.
  • Revision ID: andrew.bennetts@canonical.com-20101214231444-uubf7zjbg8q92ocs
Merge lp:bzr.

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/builtins.py
3749
3749
    with bzr send. If neither is specified, the default is the upstream branch
3750
3750
    or the branch most recently merged using --remember.
3751
3751
 
3752
 
    When merging a branch, by default the tip will be merged. To pick a different
3753
 
    revision, pass --revision. If you specify two values, the first will be used as
3754
 
    BASE and the second one as OTHER. Merging individual revisions, or a subset of
3755
 
    available revisions, like this is commonly referred to as "cherrypicking".
3756
 
 
3757
 
    Revision numbers are always relative to the branch being merged.
3758
 
 
3759
 
    By default, bzr will try to merge in all new work from the other
3760
 
    branch, automatically determining an appropriate base.  If this
3761
 
    fails, you may need to give an explicit base.
 
3752
    When merging from a branch, by default bzr will try to merge in all new
 
3753
    work from the other branch, automatically determining an appropriate base
 
3754
    revision.  If this fails, you may need to give an explicit base.
 
3755
 
 
3756
    To pick a different ending revision, pass "--revision OTHER".  bzr will
 
3757
    try to merge in all new work up to and including revision OTHER.
 
3758
 
 
3759
    If you specify two values, "--revision BASE..OTHER", only revisions BASE
 
3760
    through OTHER, excluding BASE but including OTHER, will be merged.  If this
 
3761
    causes some revisions to be skipped, i.e. if the destination branch does
 
3762
    not already contain revision BASE, such a merge is commonly referred to as
 
3763
    a "cherrypick".
 
3764
 
 
3765
    Revision numbers are always relative to the source branch.
3762
3766
 
3763
3767
    Merge will do its best to combine the changes in two branches, but there
3764
3768
    are some kinds of problems only a human can fix.  When it encounters those,
3788
3792
    you to apply each diff hunk and file change, similar to "shelve".
3789
3793
 
3790
3794
    :Examples:
3791
 
        To merge the latest revision from bzr.dev::
 
3795
        To merge all new revisions from bzr.dev::
3792
3796
 
3793
3797
            bzr merge ../bzr.dev
3794
3798
 
4204
4208
    last committed revision is used.
4205
4209
 
4206
4210
    To remove only some changes, without reverting to a prior version, use
4207
 
    merge instead.  For example, "merge . --revision -2..-3" will remove the
4208
 
    changes introduced by -2, without affecting the changes introduced by -1.
4209
 
    Or to remove certain changes on a hunk-by-hunk basis, see the Shelf plugin.
 
4211
    merge instead.  For example, "merge . -r -2..-3" (don't forget the ".")
 
4212
    will remove the changes introduced by the second last commit (-2), without
 
4213
    affecting the changes introduced by the last commit (-1).  To remove
 
4214
    certain changes on a hunk-by-hunk basis, see the shelve command.
4210
4215
 
4211
4216
    By default, any files that have been manually changed will be backed up
4212
4217
    first.  (Files changed only by merge are not backed up.)  Backup files have
4242
4247
    target branches.
4243
4248
    """
4244
4249
 
4245
 
    _see_also = ['cat', 'export']
 
4250
    _see_also = ['cat', 'export', 'merge', 'shelve']
4246
4251
    takes_options = [
4247
4252
        'revision',
4248
4253
        Option('no-backup', "Do not save backups of reverted files."),