feature request: replicate stripping of revisions

[Brendan Cully]

On Tuesday, 04 December 2007 at 16:21, Matt Mackall wrote:
> On Tue, Dec 04, 2007 at 11:10:38PM +0100, Zbynek Winkler wrote:
> > On 04/12/2007, Matt Mackall <mpm at selenic.com> wrote:
> > > On Tue, Dec 04, 2007 at 08:18:15PM +0100, Zbynek Winkler wrote:
> > > > On 03/12/2007, Theodore Tso <tytso at mit.edu> wrote:
> > > > > And yes, I could use some other tool like mq, but
> > > > > it's rather a pain, and ultimately it was the ease of being able to do
> > > > > "git commit --amend" and "git rebase --interactive HEAD^^^" which is
> > > > > why I ultimately swtiched e2fsprogs development from hg to git.
> > > >
> > > > I recently started with mq. I use hg for some time and I felt it was
> > > > time to improve some of my processes. And I agree it is not as joyful
> > > > as one could imagine. Especially after checking out what "git rebase"
> > > > does ;-). That would fit my work flow so much better. Are there any
> > > > plans to add something like that to hg or mq? The merge strategy for
> > > > mq looks somewhat similar to git rebase so maybe we are not that far
> > > > away? Thanks.
> > >
> > > I believe transplant is most of rebase, but I've never used either.
> > 
> > Thanks for pointing that out. I've seen it when I was out for
> > something that would help me but picked mq at the time. Reading about
> > git rebase I now see that transplant can be used in a similar way to
> > git rebase but the git rebase description fits my use case much much
> > better. I think that what confused me in the description of
> > 'transplant' was the remote repository as the source to transplant
> > from. Focusing on the single repo in 'rebase' description caused the
> > a-ha moment for me.
> > 
> > After playing with it a little it seems that 'transplant' is almost
> > like 'rebase' but missing the 'strip' found in mq. Isn't that so?
> 
> I'm not sure what the fundamentals of rebase are. Transplant, if I
> understand it correctly, effectively replays changesets as if they
> were patches. I believe it currently has trouble replaying merge
> changesets, but I may be wrong. And it leaves the originals intact.

that's exactly right, and it does ignore merges. Ideally it would
operate more like a streamlined MqMerge, and would be able to strip
old branches on request.

At some point it might be worth refactoring mq a bit to provide a
common history-modifying layer and then providing the quilt-like stuff
in mq and rebase code in transplant or some other extension that could
provide amend etc.

> Making an hg rebase that did either "transplant + strip" or "qimport;
> qpop; qpush; qdel" would give us something very like rebase, modulo
> handling of merge changesets.
> 
> If people really want something more like rebase, we can probably make
> that happen.