The Mercurial way of doing it?

[Colin Caughie]

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Christian Boos
> Sent: 13 December 2009 15:48
> To: Nicolas Dumazet
> Cc: Tom Medhurst; mercurial at selenic.com
> Subject: Re: The Mercurial way of doing it?
>
> Nicolas Dumazet wrote:
> > Hello!
> >
> > 2009/12/13 Tom Medhurst <tom.medhurst at googlemail.com>:
> > [...]
> >
> >> ...which in Git; reverts back all the changesets in the cust-
> bike_dock
> >> branch, then applies all the missing release-v2 changesets, then
> reapplies
> >> the bike-dock changes. This is all done with the following
> command:
> >> git rebase --onto release-v2 release-v1 cust-bike_dock
> >> I was wondering how can I do this in Mercurial? Should I use
> >> patch-queues/tags/bookmarks/branches? Can I rebase from one
> parent to
> >> another?
> >>
> >
> > Yes you can!
> >
> > I think that the Rebase extension, distributed with mercurial,
> should
> > pretty much fit your needs.
> > Have a look at http://mercurial.selenic.com/wiki/RebaseExtension
> >
>
> However, there's a caveat for the specific scenario you're
> interested
> in, as you'll end up with:
>
>             |---------[release-v2] o----o[cust-bike_dock]
>  [master]o--|                          /
>             |---------[release-v1] ---
>
> i.e. the first rebased changeset from cust-bike_dock will be a merge
> changeset.
> See http://mercurial.selenic.com/bts/issue1950 for some details. In
> short, it seems to work as designed, whether this is a good thing or
> might be changed if possible is up for discussion.

I think the transplant extension is what's needed here, not rebase. Transplant will splice the changesets in [cust-bike_dock] onto [release-v2] without pulling everything from [release-v1] with it as well.

I haven't used it in this way before though so I'm not sure what the command line would be.

Colin


Latest News at: http://www.indigovision.com/news2009.php