Jeff Schwartz <jefftschwartz@xxxxxxxxx> writes:
> Using interactive rebase has one flaw IMHO and that is the way it
> handles dating its commit. Can you add an option to interactive rebase
> that would make it use the date from the commit that is most recent
> and not the date from the commit that is the oldest?
I am not sure what you mean by this. If you interactively rebase
the topmost two commits (assuming that since three commits ago, you
have a linear history):
$ git rebase -i HEAD~2
and tell the editor that you want to 'edit' both instead of just
'pick'ing, the command will give you control back for both of these
two commits, and you can say "git rebase --continue".
o----X----Y (original history)
\
\
X'----Y' (rebased history)
After the exercise, the two new commits that replaced the two
commits from the original history
(1) retain their own author timestamp; and
(2) record the time when these new commits are created as the
committer timestamp.
So there is no "most recent" or "oldest" timestamp in the series
involved. The author timestamp of commit X' (which corresponds to
the commit X in the original history) in the rewritten history is
the same as the author timestamp of commit X. Same for the author
timestamps of commit Y and Y'.
The committer timestamp of commit X' and commit Y' are the actual
time each step of your "rebase -i" operation creates them, which
should be more recent than those of commit X and commit Y, unless
your clock or the clock on the machine on which X and Y were created
are not in sync with the real world.
