From: Johannes Sixt <j6t@kdbg•org>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>
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 17:28:33 +0200 [thread overview]
Message-ID: <8b7df500-4ddd-4aa4-bc67-b1b345c806e6@kdbg.org> (raw)
In-Reply-To: <52fd63c0-cd43-4ae8-af3e-f3fae02eaabf@app.fastmail.com>
Am 16.10.25 um 16:13 schrieb Kristoffer Haugsbakk:
> 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)?
The cited example talks about a set of patches and expects them to
create the same object IDs each time they are imported. This expectation
only makes sense when the import happens on the same base commit. But
then, why in the world would one want to import the same patches
multiple times??
A mailbox full of patches is not a suitable storage form for commits.
This particular use-case for git-am just does not make sense.
> 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.
It certainly depends on the case. I think I would begin by putting the
warning last and then judge whether a better place is warranted.
>> 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.
Fair enough.
> 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: ...
I do not like the latter. If you do not like the former, I wouldn't mind
not adding the sentence. The warning should be sufficient.
-- Hannes
next prev parent reply other threads:[~2025-10-16 15:28 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
2025-10-16 15:12 ` Kristoffer Haugsbakk
2025-10-16 15:28 ` Johannes Sixt [this message]
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=8b7df500-4ddd-4aa4-bc67-b1b345c806e6@kdbg.org \
--to=j6t@kdbg$(echo .)org \
--cc=code@khaugsbakk$(echo .)name \
--cc=git@vger$(echo .)kernel.org \
--cc=kristofferhaugsbakk@fastmail$(echo .)com \
--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