[issue3010] Rebase to ancestor

Ethan Tira-Thompson bugs at mercurial.selenic.com
Thu Sep 15 14:09:52 CDT 2011

New submission from Ethan Tira-Thompson <ejt at cmu.edu>:

(summarizing from mailing list, links below)

Rebase currently supports non-ancestor destinations, but it would be helpful 
to also support ancestoral destinations.  This case may require a different 
implementation than is used for the case of rebasing onto a branch, but is 
still a valid operation that comes up in practice.  (e.g. a bugfix (A) that 
should be moved into a new branch off of a previous 'public' changeset, so 
that the bugfix can be pushed without having to share the incomplete feature 
development (B)).

In other words, given:

  ... [A0] --- [B0] --- [B1] ... [Bm] --- [A1] --- [A2] ... [An]

desired outcome of ' rebase -s A1 -d A0 ':

  ... [A0] --- [B0] --- [B1] ... [Bm]
           [A1'] --- [A2'] ... [An']

I've used this approach to kickoff the rebase:
  hg update -r A0
  hg transplant A1 #becomes A1'
  hg rebase -s A2 -d A1'
  hg strip A1

Martin Geisler suggested this approach:
  hg update Bm
  hg revert --all --rev A0
  hg commit -m "A0'"
  hg rebase --base An
  hg export A1' A2' ... An'
  hg update A0
  hg import A1' A2' ... An'
  hg strip A0'

I don't know the subtleties well enough to evaluate the "right" way to do 
this, which is why I'd rather have rebase handle this natively to be less 

See mailing list thread:


messages: 17477
nosy: ejtttje
priority: feature
status: unread
title: Rebase to ancestor
topic: rebase

Mercurial issue tracker <bugs at mercurial.selenic.com>

More information about the Mercurial-devel mailing list