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

[Stefano Tortarolo]

2010/1/11 Matt Mackall <mpm at selenic.com>

> On Sat, 2010-01-09 at 14:26 +0100, Stefano Tortarolo wrote:
> > 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
>
> Definitely 2.
>

Yep.



> > 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)
>
> Using the supplied order I think results in least surprise.
>

Ok, I'm quite busy now. This week-end I should be able to code something.
Do you have other suggestions about --detach? This feature is strongly
related to that one.

Cheers,
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100112/3b61894d/attachment.htm>