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

From: Junio C Hamano <gitster@pobox.com>
Date: May 7, 2019, 04:19 UTC
Message-ID: <xmqqtve6nbfv.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <alpine.DEB.2.20.1905010900260.23829@perkele.intern.softwolves.pp.se>

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

Show 15 quoted lines

> Junio C Hamano:
>
>>> 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):
>
> 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.

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.