From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
"Stefan Haller" <lists@haller-berlin.de>,
Git <git@vger.kernel.org>
Subject: Re: Would it make sense to add a commit.signOff config?
Date: Tue, 16 Dec 2025 11:29:20 +0900 [thread overview]
Message-ID: <xmqqwm2n40sf.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BGCwjTBEi4wkg=065QofiO9ZL+9XVCCcTiHriXqgH1Szw@mail.gmail.com> (Elijah Newren's message of "Mon, 15 Dec 2025 16:17:21 -0800")
Elijah Newren <newren@gmail.com> writes:
>> diff --git c/Documentation/signoff-option.adoc w/Documentation/signoff-option.adoc
>> index cddfb225d1..0b869dfbe4 100644
>> --- c/Documentation/signoff-option.adoc
>> +++ w/Documentation/signoff-option.adoc
>> @@ -16,3 +16,15 @@ endif::git-commit[]
>> +
>> The `--no-signoff` option can be used to countermand an earlier `--signoff`
>> option on the command line.
>> ++
>> +As it makes it harder to argue against one who tells the court "the
>> +log message of the commit ends with a Signed-off-by trailer by person
>> +X, but it is very plausible that it was done by inertia without person
>> +X really intending to certify what DCO says, hence the Signed-off-by
>> +trailer is meaningless", if we add more publicized ways to add
>> +sign-off automatically, Git does not (and will not) have a
>> +configuration variable to enable the `--signoff` command line option
>> +it by default.
>> ++
>> +There exists `format.signoff`, but that is a historical mistake, and
>> +it is not an excuse to pile on more mistakes of the same kind on top.
>
> This feels like it's missing context (it'll take the reader a while to
> figure out why the paragraphs are there and that the two are related),
Very true. It may be sufficient to leave this part unmodified,
keep the updates to gitfaq document, and do nothing else.
next prev parent reply other threads:[~2025-12-16 2:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-14 16:10 Would it make sense to add a commit.signOff config? Stefan Haller
2025-12-14 16:44 ` Carlo Marcelo Arenas Belón
2025-12-14 23:44 ` Junio C Hamano
2025-12-14 23:52 ` Collin Funk
2025-12-15 1:22 ` brian m. carlson
2025-12-15 1:59 ` Junio C Hamano
2025-12-15 22:29 ` brian m. carlson
2025-12-16 1:20 ` Junio C Hamano
2025-12-16 0:17 ` Elijah Newren
2025-12-16 2:29 ` Junio C Hamano [this message]
2025-12-16 7:10 ` Johannes Sixt
2025-12-16 7:15 ` Johannes Sixt
2025-12-16 18:54 ` [PATCH v2] commit: document that $command.signoff will not be added Junio C Hamano
2025-12-16 19:48 ` Elijah Newren
2025-12-17 4:47 ` Junio C Hamano
2025-12-17 7:40 ` Elijah Newren
2025-12-17 13:51 ` Johannes Sixt
2025-12-17 23:16 ` Junio C Hamano
2025-12-19 7:33 ` Kristoffer Haugsbakk
2025-12-19 12:52 ` Junio C Hamano
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=xmqqwm2n40sf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=lists@haller-berlin.de \
--cc=newren@gmail.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).