[PATCH 0 of 2] Cherry picking with rebase

[Matt Mackall]

On Wed, 2009-04-01 at 12:04 +0200, Stefano Tortarolo wrote: 
> 2009/3/31 Matt Mackall <mpm at selenic.com>:
> > On Sun, 2009-03-29 at 22:28 +0200, Stefano Tortarolo wrote:
> >> These patches allows to rebase just some revisions of a branch.
> >> e.g. rebase -s x --upto x+3 -d y
> >>
> >> It's important to notice that rebasing an intermediate
> >> revision implies rebasing also their parents up to its base.
> >
> > Yeah. That's not what's wanted here. If I have:
> [...]
> 
> Yes, you're right. I should I've said: "with current rebase you can
> only rebase base revisions, if you don't want to maintain the
> relationship with that branch, so cherry picking using rebase so far
> requires pulling in also those revisions".
> The point is that we need to either create a different extension or
> modify rebase.
> 
> > All we need for this is revert and merge operations. Also note that we
> > can revert a whole range of changes between b and d in one step, if
> > needed.
> 
> So if I have undestood correctly you just revert all the unwanted
> revisions (working on a temporary branch) and then merge what remains?

Basically, yes.

> > We can probably also think of this as a pair of rebase-like operations.
> > One to transplant d onto the common ancestor b, then one to move it onto
> > the branch.
> 
> Ok, but you cannot do that transplanting with rebase, right?
> 
> I need some time to think about this, but at a first glance it seems
> like rebase doesn't fit well here.

Well, first off it wants rebase's pseudo-merge magic, and second it
wants rebase's resume-after-interactive-merge magic.

Whether it makes sense for this functionality to be named 'rebase' isn't
clear though. It might want to be 'transplant' instead.

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