rebasing only a single changeset
Matt Mackall
mpm at selenic.com
Thu Nov 27 01:15:24 UTC 2008
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.
There might be a way to make rebase more clever about such things, but
it would take some thinking.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list