Re: Request to add option to interactive rebase to preserve latest commit date

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 26, 2019, 14:32 UTC
Message-ID: <xmqq4l6kvnuu.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAL3M-FZ7b3H7Z+Vr9Wbey5iYVoWiUBnDKVEenyAMrUXeNfL56w@mail.gmail.com>

Jeff Schwartz <jefftschwartz@gmail.com> 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.