[PATCH 2 of 2] rebase: add --cherrypick to cherrypick single revisions

Matt Mackall mpm at selenic.com
Mon Jan 4 15:37:37 CST 2010


On Sat, 2010-01-02 at 18:50 +0100, Stefano Tortarolo wrote:
> 2009/12/31 Matt Mackall <mpm at selenic.com>:
> > On Thu, 2009-12-31 at 02:50 +0100, Stefano Tortarolo wrote:
> >> # HG changeset patch
> >> # User Stefano Tortarolo <stefano.tortarolo at gmail.com>
> >> # Date 1262222630 -3600
> >> # Node ID 4643de06fb4d42ea22055d42ce9ff46762f30555
> >> # Parent  fcedd4d4282f33be5f86cd3a311bf937fe07528e
> >> rebase: add --cherrypick to cherrypick single revisions
> >>
> >> Using the idea behind --detach, rebase can now 'copy' single revisions from
> >> a branch to another one.
> >> Basically, it ignores every changeset up to the requested one, by means of null
> >> merges, and then rebases just the specified changeset.
> >
> > Nice. This is different enough from normal rebasing that it probably
> > wants a separate command under the same extension. Something like:
> >
> > hg port --dest stable A B C:D
> 
> Yes, my intention was to get some feedbacks and then propose a separate command.
> Just one question: why 'port'?

I don't like 'cherrypick' and wanted something different. First, because
it's a misspelling. Second, because what you've implemented (and what
git's implemented) is only the easy part of what's historically been
described as cherry-picking: transplanting a change. The other piece is
doing the right thing with future merges and cherry-picks which is too
nebulous to actually implement.

I picked 'port' only because I couldn't think of anything better and
'transplant' was already taken.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list