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

[Stefano Tortarolo]

2010/1/4 Matt Mackall <mpm at selenic.com>:
> On Sat, 2010-01-02 at 18:50 +0100, Stefano Tortarolo wrote:
>> 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.

Ok, let's stick with 'port', we can as well change it later.
I've written some code that allows to copy multiple revisions (e.g., port -d
2 4 5:8), I hope to be able to post something in the next few days.
However, I've got one tricky point...
Let's say we've got the following repository:

    G
 /
A - E - F
 \
  B - C - D

What should we do if someone tried to do: hg port -d G F C?
1) Abort saying that only one source branch can be specified
2) Handle the request

The latter choice, that I'm trying to implement, seems nicer but we'd have
to:
- detect the different branches and calculate the ancestors for each
revision (we must 'null-merge' them)
- define an order in which the revision will be managed, if the specified
order matters (i.e. port -d G F C is different to port -d G C F)

Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100109/ac85589a/attachment.htm>