Re: [PATCH] doc: warn against --committer-date-is-author-date

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Oct 9, 2025, 21:57 UTC
Message-ID: <6a921119-6fba-4f82-916f-d80d3f46d54d@app.fastmail.com>
In-Reply-To: <xmqqo6qfda78.fsf@gitster.g>

On Thu, Oct 9, 2025, at 23:41, Junio C Hamano wrote:

Show 11 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>>>  You should only use
>>> +	this option to lie about the committer date when applying
>>
>> s/lie/override/ ?
>
> It cannot be "fixing an earlier mistake by overriding the correct
> data".  It is deliberately using a data that does not match the
> reality to replace what was recorded, so in this case, "lie" would
> be the proper characterization, I would think.

Okay. I don’t think he was saying “fix” but just the more neutral “override”.

I was more confused last year[1] about the use-case here, in turn more dismissive; I thought that it was just a vanity thing. I’m all for dictating what the author date is since that’s my judgement to make, and moreover such fiddling is naturally tempered by common sense. (Did I author this between one month ago and now: yes, because I originally wrote it one month ago and then amended it three times in this timestamp. Did I author this *three months* ago: No, I hadn’t even thought about it at that point. That’s just a lie).

It’s easy to have a common sense for the authoring date because everyone knows of “authoring”. It’s more difficult for people to have common sense for the commit date if they don’t know what “committer” is for.

I guess I like the pointed “lie” in this case because uncareful lying can cause technical issues. So you better sharpen your senses and have a real reason for doing it.

🔗 1: https://lore.kernel.org/git/93041214-4774-49eb-b8bd-24648134cded@app.fastmail.com/

>
>[snip]