rebasing only a single changeset

[Matt Mackall]

On Wed, 2008-11-26 at 17:43 -0800, L. David Baron wrote:
> On Wednesday 2008-11-26 19:15 -0600, Matt Mackall wrote:
> > On Wed, 2008-11-26 at 10:27 -0500, Benjamin Smedberg wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Mozilla is going to cut a long-lived release branch shortly. We will be
> > > cherry-picking individual changes from the trunk to the release branch. I
> > > originally thought that the rebase extension would be perfect for this task:
> > > 
> > > hg rebase -s revtocherrypick -t releasebranch
> > > 
> > > But I forgot that rebase will not rebase the single revision I'm interested
> > > in: it will only rebase entire branches.
> > > 
> > > The transplant extension could be used for this, but doesn't do 3-way
> > > merging (and the rebase extension is in general better designed). How hard
> > > would it be to add "rebase a single revision" to the rebase extension?
> > 
> > Actually, it's not a good match for cherry-picking, because the typical
> > change to cherry-pick will not be rooted at a branch point. This is a
> > little confusing but consider this graph:
> > 
> > a-b-c-d-e  <= devel
> >    \
> >     f-g-h  <= stable
> > 
> > If we want to copy just e onto the stable branch, we can't simply merge
> > e onto h (which is how rebase does things). Merge is about combining the
> > state of the entire project at e with the entire project at h, but
> > really we're just interested in the delta from d to e and not in changes
> > c and d.
> 
> It seems to me that the basic operation of merging can be seen as a
> function with two nodes as inputs, merge2(e, h) using the example
> above, or as a function with three nodes as inputs, where
> merge2(e, h) == merge3(e, h, b), since b is the closest common
> ancestor of e and h.  Given that, isn't the act of cherry-picking
> just using this merge3 function with a different base -- in this
> case, merge3(e, h, d) ?  (And then, since we're rebasing, giving the
> resulting changeset only one parent.)
> 
> To put it slightly differently, what I think we want is to use a
> graph that's like the graph above, except has some of the arrows
> reversed (and ignoring a, since it doesn't matter):
> 
>   d-e
>    \
>     c-b-f-g-h
> 
> and then rebase e onto h.

I think that makes some sense in the abstract. Not sure how Mercurial
will feel about it though, as it has some ideas about which order time
runs in. In particular, it knows that any ancestor of h has a lower
revision number, which d here might not.

For a simple merge, it might be exactly what's wanted. We'll actually
ignore c-b-f-g-h and consider only the contents of d, e, and h. But
rename tracking might get confused.

Anyway, it's worth trying. We've actually already got some logic in
rebase that temporarily asserts different ancestors, so this might be
fairly easy to hack in.

[adding stefano to the cc:]

-- 
Mathematics is the supreme nostalgia of our time.