When is merge -r cherry-picking?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/2010 01:49 PM, Eli Zaretskii wrote:
> I'm confused about when "bzr merge -r" is cherry-picking and when it
> isn't.  On the one hand, the docs of merge says:
> 
>   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”.
> 
> which seems to imply that whenever --revision is used the merge
> becomes cherrypicking.

I think "like this" is meant to refer to "If you specify two values".

Cherrypicking is when you apply some, but not all of the changes present
in a revision.  It can mean specifying a base revision that is not an
ancestor in the working tree's branch, or it can mean restricting the
merge to certain files or hunks, e.g. using merge -i.

If you have done a cherrypick, "bzr status" will not list the outcome as
a pending merge.

> OTOH, it keeps silent about the use-case where
> the argument to --revision specifies less than 2 values, and one of
> the examples says:
> 
>   To merge changes up to and including revision 82 from bzr.dev:
> 
>   bzr merge -r 82 ../bzr.dev
> 
> which seems to imply that "bzr merge -r 82" is a real merge, not
> cherrypicking.

Correct.  If you run "bzr status" after a merge like that, you'll see a
pending merge listed.  (Unless you've already merged 82, in which case
it will do nothing at all.)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzcSogACgkQ0F+nu1YWqI1xdgCeJM5u2C4l2NXl8P19phAIiett
oZcAn3u9j7MolYZXIaaacLppiO0pv/ez
=ePq8
-----END PGP SIGNATURE-----