rebase to ancestor: just do it

[Ethan Tira-Thompson]

Great I think this is what I’m getting at :)  Different branch topologies may require slightly different handling, but as long as the user intention is unambiguous, I’d prefer rebase do the requested operation instead of simply refusing.

In other words, from your very nice description earlier, it sounds like you handle the case of the destination *not* being an ancestor using optimal methods for that topology, but that doesn’t prevent you from using a different approach when the destination *is* and ancestor, e.g. you describe this solution:

> where [A0'] has the same file content at [A0], and then rebasing A1...An
> onto A0':
> 
>  ... [A0] --- [B0] --- [B1] ... [Bm]
>                                     \
>                                      [A0'] --- [A1'] --- [A2'] ... [An']
> 
> Since [A0] and [A0'] are identical, we can change the ancestor of [A1']
> to [A0] and get the same diff in [A1'] (this changes the hash again):
> 
>  ... [A0] --- [B0] --- [B1] ... [Bm]
>          \
>           [A1''] --- [A2''] ... [An'']

I’m by no expert (which is why I’d rather rebase handle this internally) but what about the approach I was using:
  hg update -r A0
  hg transplant A1 #becomes A1'
  hg rebase -s A2 -d A1’
  hg strip A1
basically start a new branch from A0 using A1, and then use the “normal” rebase to put the rest of An onto the new A1’.  This seems simpler but perhaps it’s more prone to conflicts or something?

Thanks,
  -Ethan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110912/4d2aea6b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3715 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20110912/4d2aea6b/attachment.bin>