[RFC] rebase --collapse

[Giorgos Keramidas]

On Thu, 14 Aug 2008 23:05:33 +0300, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> On Thu, 14 Aug 2008 22:15:06 +0300, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
>> On Thu, 14 Aug 2008 21:05:25 +0200, Stefano Tortarolo  wrote:
>>> This could be implemented easily also for "normal" behaviour, would
>>> this be useful?  I don't think I'd use it, but if you want it there's
>>> no problem.
>>
>> I don't normally use the qdel --keep option either, but I can imagine
>> cases when it would be a bit useful.  If adding something like this to
>> the rebase extension is going to make things more complex, or it is a
>> major PITA to add, then it doesn't matter very much I guess :)
>
> Very cool!  I just read change 68431825ea42 at
> http://www.bitbucket.org/astratto/rebase-soc/changeset/68431825ea42
>
> Thanks for adding it so fast :)

One of the 'tricky' parts I just noticed is that rebase and transplant
may have odd interactions.

For example, by starting with a history of:

  o  2[tip]:0   77b5fd73a9f8   2008-08-14 20:29 +0000   keramida
  |    Use EXIT_SUCCESS from stdlib.h
  |
  | @  1   a9d8831c9ff6   2008-08-14 23:11 +0300   keramida
  |/     Add missing newline.
  |
  o  0   aa3c27ae2f9e   2008-08-14 23:11 +0300   keramida
       Initial revision.

I can rebase 2:77b5fd73a9f8 on top of 1:a9d8831c9ff6 and it works fine.
If I transplant the rebased changeset on top of 0:aa3c27ae2f9e again,
and try to rebase it a second time I get:

  % pwd
  /tmp/hgtest/alice
  % hg glog
  o  2[tip]:0   77b5fd73a9f8   2008-08-14 20:29 +0000   keramida
  |    Use EXIT_SUCCESS from stdlib.h
  |
  | @  1   a9d8831c9ff6   2008-08-14 23:11 +0300   keramida
  |/     Add missing newline.
  |
  o  0   aa3c27ae2f9e   2008-08-14 23:11 +0300   keramida
       Initial revision.

  % hg rebase --source 2
  abort: cannot rebase an ancestor
  %

Trying it the other way around works fine:

  % hg up -C 2
  % hg rebase -s 1

My intuition says that it shouldn't matter in this simple history graph
if I rebase 1 on top of 2 or vice versa.  Am I missing something crucial
about the way rebase works?

One final suggestion I would like to make is to add in key places of the
rebase extension debugging output.  The command

  % hg --debug rebase --source 2
  abort: cannot rebase an ancestor
  %

is not very useful right now.  But it could be made a lot more useful if
we added tracing/debugging output to `rebase.py' that showed what it is
trying to do while it runs.