[RFC] rebase --collapse

[Giorgos Keramidas]

On Fri, 15 Aug 2008 00:04:29 +0300, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
>> Currently if --dest is not specified it defaults to branch head, you
>> should try with hg rebase -s 2 -d 1.
>
> Ah!  That makes sense, yes.  I thought it would rebase on the
> current workspace parent.

Another thing I just noticed is that commit dates change to the time of
the rebase operation.  Is there any way to 'preserve' the commit dates
of the rebased changes?  Should we add such a feature?

As an example, I started with the same test repository as before:

  % hg glog
  @  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.

  %

then rebased 2 on top of 1 with:

  % hg rebase -s 2 -d 1
  merging hello.c
  [editor fires up and resolves conflict]
  saving bundle to /tmp/hgtest/alice/.hg/strip-backup/77b5fd73a9f8-temp
  adding branch
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  rebase completed
  %

But the rebased changeset now has a modified date (the date it was
rebased, instead of the date it was originally committed):

  % hg glog
  @  2[tip]   4a409fb839c5   2008-08-15 00:03 +0300   keramida
  |    Use EXIT_SUCCESS from stdlib.h
  |
  o  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 definitely understand both ways of looking at this.

  (1) Some users may want to preserve the commit dates of the original
      changeset (for example because they want to check later and see
      when a change was originally developed instead of when it was last
      rebased).

  (2) Some other users may not care about the original patch date, but
      would be fine with the rebase date in the commit history.  In
      fact, they may like it better because commits would be easier to
      graft in a linear sequence that has a monotonically increasing
      timestamp for all changes (instead of going back and forth in
      time, as revision numbers grow upwards).

The MQ extension preserves the original commit date by default, and it
includes the following options in an effort to satisfy both user groups:

  % hg help qrefresh
  [...]
   -D --currentdate  add "Date: <current date>" to patch
   -d --date         add "Date: <given date>" to patch

Do you think we could add this sort of commit date handling to rebase
too?  Would it be useful to have something like that?