Re: using oldest date when squashing commits

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Oct 27, 2023, 12:34 UTC
Message-ID: <70b8d4d8-f4b5-4cd7-b73a-1d7393d84266@xiplink.com>
In-Reply-To: <59731c05-c3f6-4815-8411-783bb1c2aac4@kdbg.org>

On 2023-10-24 17:19, Johannes Sixt wrote:

Show 21 quoted lines

> Am 24.10.23 um 19:30 schrieb Junio C Hamano:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>>> "fixup -c/-C" were conceived as a way to reword a commit message at
>>> the same time as optionally fixing up the commit's content.
>>
>> Yup, it still is a "fix", meaning the identity and the spirit of the
>> commit being fixed are unchanged.
> 
> That's a pitty, because that is not at all what *I* use "fixup -C" for.
> To update the commit message, I use "squash" (or occasionally "reword").
> I use "fixup -C" after the following events:
> 
> 1. Commit unfinished changes for whatever reason. Usually the commit
> message just says "WIP <topic>" because that's what it is.
> 2. Make a fixup commit for an earlier commit because doing the fixup now
> gets it out of the way, and often delaying it until after the completed
> change would cause merge conflicts.
> 3. Complete the WIP including the commit message.
> 
> I would now use "fixup -C" on commit 3, because its metadata reflects
> reality more accurately than that of 1. Commit 3 often comes days after 1.

Speaking of the metadata ...

I never use "fixup -C" (or -c), but I do use squash/fixup a lot. I find that I would prefer it if Git used the most recent Author date from the set of commits being combined, rather than preserving the picked commit's Author date. Sometimes it takes quite a while for me to get a piece of work sorted out, and I would rather have the Author date in the end-result commit reflect the work's completion time than its initiation time.

The current behaviour means that when scanning through commits with tools like gitk (which shows just the Author date in its list of commits) I'll often see what I feel are inaccurate or confusing dates there, and I use the Committer date (a bit less convenient in gitk) to figure out when the work was actually "done". (Although the span between the Author date from the start of the work and the Committer date from the end of the work would roughly reflect how long the work took to complete, I don't use Git for that kind of information.)

Anyway, this is a minor itch for me that I've never felt the need to scratch. I just thought I'd mention it since the topic is being discussed.

M.