From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com>
To: "Johannes Sixt" <j6t@kdbg•org>
Cc: "Kristoffer Haugsbakk" <code@khaugsbakk•name>,
git@vger•kernel.org, "Phillip Wood" <phillip.wood@dunelm•org.uk>
Subject: Re: [PATCH] doc: warn against --committer-date-is-author-date
Date: Thu, 16 Oct 2025 16:13:11 +0200 [thread overview]
Message-ID: <52fd63c0-cd43-4ae8-af3e-f3fae02eaabf@app.fastmail.com> (raw)
In-Reply-To: <601b145d-b183-4101-acb3-4a32b2ec4380@kdbg.org>
Good afternoon Hannes
On Sat, Oct 11, 2025, at 11:15, Johannes Sixt wrote:
> Am 08.10.25 um 21:45 schrieb kristofferhaugsbakk@fastmail•com:
>> From: Kristoffer Haugsbakk <code@khaugsbakk•name>
>>
>> This option has legitimate uses but could create a commit history which
>> violates the assumption that commits are strictly increasing in terms of
>> commit timestamps. Warn against that in both git-am(1) and git-rebase(1).
>
> I think that the discussion has meanwhile converged insofar that we do
> not think that the option has a legitimate use case. Rather, it was
> introduced to solve one particular problem case (that is cited below),
> but with a solution that was misguided and not well thought through.
Okay if this was the cited example:
https://lore.kernel.org/git/46d6db660901221441q60eb90bdge601a7a250c3a247@mail.gmail.com/
Then we can clarify with two questions:
1. Is the use case itself reasonable, i.e. abusing[1] git-am(1) to
pseudo-import commits (modulo the committer)?
2. What is a better way to achieve this goal? (assuming (1) is true)
It seemed to me that you might as well use the author date. Unless
setting max Unix time would be better? Then at least you will never
manage to apply something on top of something with a newer commit
timestamp.
† 1: Since this is not what git-am(1) is designed for
>>[snip]
>> + NOTE: The history walking machinery assumes that commits have
>> + strictly increasing commit timestamps, with some tolerance for
>> + clock skew (see linkgit:git-rev-list[1]). You should only use
>> + this option to lie about the committer date when applying
>> + commits on top of a base which commit is older (in terms of the
>> + commit date) than the oldest patch you are applying.
>
> IMO, "NOTE" is not strong enough, it should be at least "WARNING".
Thanks. I’ll do that.
>> ++
>> +By default the command records the date from the e-mail
>> +message as the commit author date, and uses the time of
>> +commit creation as the committer date. This allows the
>> +user to lie about the committer date by using the same
>> +value as the author date.
>
> I would not mind leaving the description first and the warning in the
> follow-up paragraph. It would make for a better flow of reading.
Okay. My thought process was that this was important enough to
front-load for readers. But regarding flow: the reader can see the
all-caps keyword and skip the paragraph easily if they want/on repeated
reads.
But I’m perfectly fine with leaving it in the second paragraph.
Note: Not relevant here but in case there were more than one paragraph
on this option already: should the WARNING be the final paragraph? Or in
the second paragraph? (Like an imporant aside interruption after the
introduction.) I think the final one but just clarifying.
> Perhaps insert "Do not use this option." as the the first sentence,
> either before the description (my preference) or in the warning.
Regarding reading flow, this seems more back-and-forth than this patch.
But let’s see.
You preferred option sounds good to me.
You say “first sentence” so I guess we’re not making a one-sentence
paragraph. Like this?
Do not use this option. By default the command records the date from
the e-mail ...
WARNING: ...
In that case I think parentheses makes it read better:
(Do not use this option.) By default the command records the date from
the e-mail ...
WARNING: ...
Thanks for the review.
next prev parent reply other threads:[~2025-10-16 14:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-28 6:59 How dangerous is --committer-date-is-author-date these days? Johannes Sixt
2024-09-28 9:49 ` Phillip Wood
2024-09-28 10:04 ` Phillip Wood
2024-09-30 14:49 ` Kristoffer Haugsbakk
2024-09-30 17:08 ` Junio C Hamano
2025-10-08 20:41 ` SZEDER Gábor
2025-10-08 19:45 ` [PATCH] doc: warn against --committer-date-is-author-date kristofferhaugsbakk
2025-10-09 13:46 ` Phillip Wood
2025-10-09 14:31 ` Kristoffer Haugsbakk
2025-10-09 20:47 ` Kristoffer Haugsbakk
2025-10-09 21:58 ` Junio C Hamano
2025-10-09 22:56 ` Kristoffer Haugsbakk
2025-10-09 21:41 ` Junio C Hamano
2025-10-09 21:57 ` Kristoffer Haugsbakk
2025-10-11 9:15 ` Johannes Sixt
2025-10-16 14:13 ` Kristoffer Haugsbakk [this message]
2025-10-16 15:12 ` Kristoffer Haugsbakk
2025-10-16 15:28 ` Johannes Sixt
2025-10-16 15:42 ` Kristoffer Haugsbakk
2025-10-16 16:23 ` Junio C Hamano
2025-11-19 16:27 ` Kristoffer Haugsbakk
2025-11-20 16:26 ` [PATCH v2] " kristofferhaugsbakk
2025-11-20 17:19 ` Johannes Sixt
2025-11-26 16:02 ` Phillip Wood
2025-11-27 6:30 ` Kristoffer Haugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52fd63c0-cd43-4ae8-af3e-f3fae02eaabf@app.fastmail.com \
--to=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=code@khaugsbakk$(echo .)name \
--cc=git@vger$(echo .)kernel.org \
--cc=j6t@kdbg$(echo .)org \
--cc=phillip.wood@dunelm$(echo .)org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox