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

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?

- *Jeff*

Jeff Schwartz <jefftschwartz@gmail.com> writes:

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.

Junio C Hamano:

I sort of assume that this is when merging several fixup! or squash! commits. I often end up adding lines the code to date these with the current date, but the date of the last fixup'ed or squash'ed commit would probably be better.

Peter Krefting <peter@softwolves.pp.se> writes:

Ah, I see.  So if you have (time flows left to right, as usual):

	A---B---C

where B and C are fixup for A, the question is what's the author ident and author time should be for the resulting single commit.

I think we currently use the ident and time from the original A, and that is the only right thing to do, as I view

	$ git commit -m A
	$ edit
	$ git commit -a --fixup HEAD ;# create B to fix A
	$ edit
	$ git commit -a --fixup HEAD^ ;# create C to fix A
	$ git rebase --autosquash -i HEAD~3 ;# squash B and C into A

as merely a different way to do the following:

	$ git commit -m A
	$ edit
	$ edit further ;# working tree has an equivalent of C
	$ git commit --amend -a

The principle is "the bulk of the work was done in A, no matter what is done incrementally by squashing in or amending small refinements; the primary authorship date and time stays the same as the original".

When the person who is correcting other's change with --amend makes a contribution that is substantial enough such that the amended HEAD no longer resembles the original HEAD, there is a mechanism to let the amender take authorship, i.e. do this at the last step instead

	$ git commit --reset-author --amend -a

in the second sequence. I do not think there currently is an equivalent in "rebase -i" language to do so.

I am still not convinced it is a good idea, but I can see how another verb that behaves like existing "fixup" or "squash" but use the authorship not from the updated but from the updating commit might seem useful.

Junio C Hamano:

Indeed. My last command in the chain is usually

   git commit --amend --date=now

to set the commit date to now. In my use-case it is often a work-in-progress commit that I start out with, which I refine over a couple of hours/days/weeks to get working properly (depending on the complexity of the change), and when I am finally done, the proper dating of the change is "now", not "when I first started doing it".

I'd be happy with a parameter and/or configuration variable saying "amend and rebase uses last commit date".

Yes, exactly. When squashing or fixup-ing commits via rebase I really want "git log" to show the date and time of the rebase operation and not the date and time of the commit I rebased onto, which could be months or even years in the past. I once worked on a project where part of the code-base hadn't been touched in over a year. After performing a number of WIPs on it over a 4 month period I cleaned up the final commit using interactive rebase, squashing all the WIPs into a single commit whose message reflected the actual scope of the changes that had been made. A naive project manager with limited understanding of Git other than how to use 'git log' to oversee what us developers have been up to time-wise was enraged that we had committed changes months back and appeared to have done nothing since then. I believe that by adding an option to 'rebase -i hash' that would apply the current date and time of the operation would be an awesome addition to Git and its user base.

*Jeff*

On Tue, May 7, 2019 at 1:45 AM Peter Krefting <peter@softwolves.pp.se> wrote:

On 07/05/2019 05:19, Junio C Hamano wrote:

IIUC the effective change in authorship was noted in another thread about a perceived problem in rebase, and it just bit me as well recently (and the Github PR bot rejected my series for a mismatched author/sign-off :-(.

If a commit is edited in a `rebase -i` then I think the same can happen, resulting in the same user surprise at the change. Possibly a simple documentation note may help reduce user surprise.

-- Philip