Would it make sense to add a commit.signOff config?

Would it make sense to add a commit.signOff config?

[Stefan Haller]

I find it interesting that of all the git commands that take a --signoff
argument, format-patch is the only one that has a corresponding config
to turn it on for all invocations. I would have thought that git commit
needs this even more; I find it reasonable for users to decide that they
want to add a Signed-off-by trailer to all the commits they make.

But then, what about merge, cherry-pick, and revert? Does it make sense
to turn it on globally for those as well?

The background of this question is lazygit, which has a config for
enabling --signoff for all commits made by it. We recently had a feature
request to extend the meaning of that config to revert as well, and the
discussion came up whether that's a good idea, and if so, whether it
should also extend to cherry-pick and merge.

Any opinions about this? Since I work mostly in closed-source contexts I
don't have much experience with the meaning of Signed-off-by trailers.

-Stefan

Re: Would it make sense to add a commit.signOff config?

[Carlo Marcelo Arenas Belón]

On Sun, Dec 14, 2025 at 05:10:19PM -0800, Stefan Haller wrote:
> I find it interesting that of all the git commands that take a --signoff
> argument, format-patch is the only one that has a corresponding config
> to turn it on for all invocations. I would have thought that git commit
> needs this even more; I find it reasonable for users to decide that they
> want to add a Signed-off-by trailer to all the commits they make.
> 
> But then, what about merge, cherry-pick, and revert? Does it make sense
> to turn it on globally for those as well?
> 
> The background of this question is lazygit, which has a config for
> enabling --signoff for all commits made by it. We recently had a feature
> request to extend the meaning of that config to revert as well, and the
> discussion came up whether that's a good idea, and if so, whether it
> should also extend to cherry-pick and merge.
> 
> Any opinions about this?

this was discussed recently[0] and the point that was made is that SOA are
meant to be relevant mainly in open source contexts and should be explicitly
given.

Carlo

[0] https://lore.kernel.org/git/xmqq4iwvfx8s.fsf@gitster.g/

Re: Would it make sense to add a commit.signOff config?

[Junio C Hamano]

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:

> this was discussed recently[0] and the point that was made is that SOA are
> meant to be relevant mainly in open source contexts and should be explicitly
> given.
>
> Carlo
>
> [0] https://lore.kernel.org/git/xmqq4iwvfx8s.fsf@gitster.g/

Thanks for a spelunking starter.

Perhaps we should resurrect a proposed patch from 2020 (which no
longer apply cleanly, but quoted to show what the additinoal text
said).

https://lore.kernel.org/git/xmqqpnfw8gyn.fsf@gitster-ct.c.googlers.com/

to save time from potential contributors?  I do not want to see new
contributors feeling they wasted their time after putting their
effort.



diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index ced5a9beab..1909551087 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -171,6 +171,13 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
 	the rights to submit this work under the same license and
 	agrees to a Developer Certificate of Origin
 	(see http://developercertificate.org/ for more information).
++
+As it makes it harder to argue against one who tells the court "that
+log message ends with a SoB by person X but it is very plausible
+that it was done by inertia without person X really intending to
+certify what DCO says, and the SoB is meaningless." to more
+publicized ways to add SoB automatically, Git does not (and will not)
+have a configuration variable to enable it by default.
 
 -n::
 --no-verify::

Re: Would it make sense to add a commit.signOff config?

[Collin Funk]

Junio C Hamano <gitster@pobox.com> writes:

> Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
>
>> this was discussed recently[0] and the point that was made is that SOA are
>> meant to be relevant mainly in open source contexts and should be explicitly
>> given.
>>
>> Carlo
>>
>> [0] https://lore.kernel.org/git/xmqq4iwvfx8s.fsf@gitster.g/
>
> Thanks for a spelunking starter.
>
> Perhaps we should resurrect a proposed patch from 2020 (which no
> longer apply cleanly, but quoted to show what the additinoal text
> said).
>
> https://lore.kernel.org/git/xmqqpnfw8gyn.fsf@gitster-ct.c.googlers.com/
>
> to save time from potential contributors?  I do not want to see new
> contributors feeling they wasted their time after putting their
> effort.

Sounds like a good idea to me since it has come up a few times and, at
least from that thread, there is wide agreement it shouldn't be added.

> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index ced5a9beab..1909551087 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -171,6 +171,13 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
>  	the rights to submit this work under the same license and
>  	agrees to a Developer Certificate of Origin
>  	(see http://developercertificate.org/ for more information).
> ++
> +As it makes it harder to argue against one who tells the court "that
> +log message ends with a SoB by person X but it is very plausible
> +that it was done by inertia without person X really intending to
> +certify what DCO says, and the SoB is meaningless." to more
> +publicized ways to add SoB automatically, Git does not (and will not)
> +have a configuration variable to enable it by default.

I think it is a bit more clear to just write "Signed-off-by" instead of
using the abbreviation SoB. That isn't used elsewhere, as far as I can
tell.

Collin

Re: Would it make sense to add a commit.signOff config?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

On 2025-12-14 at 23:44:47, Junio C Hamano wrote:
> Thanks for a spelunking starter.
> 
> Perhaps we should resurrect a proposed patch from 2020 (which no
> longer apply cleanly, but quoted to show what the additinoal text
> said).
> 
> https://lore.kernel.org/git/xmqqpnfw8gyn.fsf@gitster-ct.c.googlers.com/
> 
> to save time from potential contributors?  I do not want to see new
> contributors feeling they wasted their time after putting their
> effort.

I think this would be a fine approach or we could add an entry in the
Git FAQ (or both).  I agree that this is something that comes up
frequently and writing it down in a more visible way would be kinder to
users and mailing list participants.

> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index ced5a9beab..1909551087 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -171,6 +171,13 @@ The `-m` option is mutually exclusive with `-c`, `-C`, and `-F`.
>  	the rights to submit this work under the same license and
>  	agrees to a Developer Certificate of Origin
>  	(see http://developercertificate.org/ for more information).
> ++
> +As it makes it harder to argue against one who tells the court "that
> +log message ends with a SoB by person X but it is very plausible
> +that it was done by inertia without person X really intending to
> +certify what DCO says, and the SoB is meaningless." to more

I think the period should be replaced here by a comma since the
quotation is part of a larger sentence.

> +publicized ways to add SoB automatically, Git does not (and will not)
> +have a configuration variable to enable it by default.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Would it make sense to add a commit.signOff config?

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I think this would be a fine approach or we could add an entry in the
> Git FAQ (or both).  I agree that this is something that comes up
> frequently and writing it down in a more visible way would be kinder to
> users and mailing list participants.

Something like this, then?

---- >8 ----
Subject: [PATCH] document that foo.signoff will not be added

Every now and then we see this coming up on the list.  Let's help
new contributors who are not aware of past discussions by clearly
documenting our past consensus.

Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/gitfaq.adoc         | 15 +++++++++++++++
 Documentation/signoff-option.adoc | 12 ++++++++++++
 2 files changed, 27 insertions(+)

diff --git c/Documentation/gitfaq.adoc w/Documentation/gitfaq.adoc
index f2917d142c..656093047a 100644
--- c/Documentation/gitfaq.adoc
+++ w/Documentation/gitfaq.adoc
@@ -83,6 +83,21 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
 which quotes the filename with spaces and specifies the `--nofork` option to
 avoid backgrounding the process.
 
+[[sign-off]]
+Why not have `commit.signoff` and other configuration variables?::
+	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.
+
+
 Credentials
 -----------
 
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.

Re: Would it make sense to add a commit.signOff config?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On 2025-12-15 at 01:59:46, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > I think this would be a fine approach or we could add an entry in the
> > Git FAQ (or both).  I agree that this is something that comes up
> > frequently and writing it down in a more visible way would be kinder to
> > users and mailing list participants.
> 
> Something like this, then?

Yup, that looks good to me.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Would it make sense to add a commit.signOff config?

[Elijah Newren]

On Sun, Dec 14, 2025 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > I think this would be a fine approach or we could add an entry in the
> > Git FAQ (or both).  I agree that this is something that comes up
> > frequently and writing it down in a more visible way would be kinder to
> > users and mailing list participants.
>
> Something like this, then?
>
> ---- >8 ----
> Subject: [PATCH] document that foo.signoff will not be added
>
> Every now and then we see this coming up on the list.  Let's help
> new contributors who are not aware of past discussions by clearly
> documenting our past consensus.
>
> Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  Documentation/gitfaq.adoc         | 15 +++++++++++++++
>  Documentation/signoff-option.adoc | 12 ++++++++++++
>  2 files changed, 27 insertions(+)
>
> diff --git c/Documentation/gitfaq.adoc w/Documentation/gitfaq.adoc
> index f2917d142c..656093047a 100644
> --- c/Documentation/gitfaq.adoc
> +++ w/Documentation/gitfaq.adoc
> @@ -83,6 +83,21 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
>  which quotes the filename with spaces and specifies the `--nofork` option to
>  avoid backgrounding the process.
>
> +[[sign-off]]
> +Why not have `commit.signoff` and other configuration variables?::
> +       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.

This feels kind of hard to parse for me.  Maybe it's just the lack of
sentence breaks, particularly near the end.  Let me take a stab at an
alternative:

Git intentionally does not (and will not) provide a configuration variable,
such as `commit.signoff`, to automatically add `--signoff` by default.
The reason is to protect the legal and intentional significance of a sign-off.
If there were more automated and widely publicized ways for sign-offs to be
appended, it would become easier for someone to argue later that a
"Signed-off-by" trailer was just added out of habit or by automation,
without the committer's full awareness or intent to certify their agreement
with the Developer Certificate of Origin (DCO) or a similar statement.
This would weaken the sign-off’s value and could undermine its credibility
in legal or contractual situations. To uphold the integrity of a sign-off,
Git only adds it when explicitly requested, rather than through automatic
configuration settings.

Maybe the last sentence or two are a bit redundant and could be
stricken.  Anyway, thoughts?

> ++
> +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.
> +
> +
>  Credentials
>  -----------
>
> 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),
and isn't as helpful to someone just trying to understand which
command line flags exist and what they do.  Maybe combine the two new
paragraphs?  Or, perhaps just a shorter version that just refers to
the FAQ?  The latter might be something like:

Git does not (and will not) have a configuration variable to enable
the `--signoff` command line option by default; see the
`commit.signoff` entry in the gitfaq for more details.
(`format.signoff`, is an exception, but it was a historical mistake,
not an excuse to pile on more mistakes.)

Re: Would it make sense to add a commit.signOff config?

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2025-12-15 at 01:59:46, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> 
>> > I think this would be a fine approach or we could add an entry in the
>> > Git FAQ (or both).  I agree that this is something that comes up
>> > frequently and writing it down in a more visible way would be kinder to
>> > users and mailing list participants.
>> 
>> Something like this, then?
>
> Yup, that looks good to me.

Thanks.

Re: Would it make sense to add a commit.signOff config?

[Junio C Hamano]

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.

Re: Would it make sense to add a commit.signOff config?

[Johannes Sixt]

Am 16.12.25 um 03:29 schrieb Junio C Hamano:
> 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.
Please do leave a pointer here. People who want to automate --signoff do
not visit gitfaq, but will search in the command's manual page.

-- Hannes

Re: Would it make sense to add a commit.signOff config?

[Johannes Sixt]

Am 16.12.25 um 01:17 schrieb Elijah Newren:
> On Sun, Dec 14, 2025 at 6:00 PM Junio C Hamano <gitster@pobox.com> wrote:
>> --- c/Documentation/gitfaq.adoc
>> +++ w/Documentation/gitfaq.adoc
>> @@ -83,6 +83,21 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
>>  which quotes the filename with spaces and specifies the `--nofork` option to
>>  avoid backgrounding the process.
>>
>> +[[sign-off]]
>> +Why not have `commit.signoff` and other configuration variables?::
>> +       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.
> 
> This feels kind of hard to parse for me.  Maybe it's just the lack of
> sentence breaks, particularly near the end.  Let me take a stab at an
> alternative:
> 
> Git intentionally does not (and will not) provide a configuration variable,
> such as `commit.signoff`, to automatically add `--signoff` by default.
> The reason is to protect the legal and intentional significance of a sign-off.
> If there were more automated and widely publicized ways for sign-offs to be
> appended, it would become easier for someone to argue later that a
> "Signed-off-by" trailer was just added out of habit or by automation,
> without the committer's full awareness or intent to certify their agreement
> with the Developer Certificate of Origin (DCO) or a similar statement.
> This would weaken the sign-off’s value and could undermine its credibility
> in legal or contractual situations. To uphold the integrity of a sign-off,
> Git only adds it when explicitly requested, rather than through automatic
> configuration settings.
> 
> Maybe the last sentence or two are a bit redundant and could be
> stricken.  Anyway, thoughts?

This is much easier to read. I'd shorten the last two sentences to

This could undermine the sign-off’s credibility in legal or contractual
situations.

-- Hannes

[PATCH v2] commit: document that $command.signoff will not be added

[Junio C Hamano]

Every now and then we see this coming up on the list.  Let's help
new contributors who are not aware of past discussions by clearly
documenting our past consensus.

Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
Helped-by: Elijah Newren <newren@gmail.com>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * The text is from Elijah and Johannes this round; I am merely
   playing a copybot.

 Documentation/gitfaq.adoc         | 19 +++++++++++++++++++
 Documentation/signoff-option.adoc |  4 ++++
 2 files changed, 23 insertions(+)

diff --git c/Documentation/gitfaq.adoc w/Documentation/gitfaq.adoc
index f2917d142c..0e40befb77 100644
--- c/Documentation/gitfaq.adoc
+++ w/Documentation/gitfaq.adoc
@@ -83,6 +83,25 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
 which quotes the filename with spaces and specifies the `--nofork` option to
 avoid backgrounding the process.
 
+[[sign-off]]
+Why not have `commit.signoff` and other configuration variables?::
+	Git intentionally does not (and will not) provide a
+	configuration variable, such as `commit.signoff`, to
+	automatically add `--signoff` by default.  The reason is to
+	protect the legal and intentional significance of a sign-off.
+	If there were more automated and widely publicized ways for
+	sign-offs to be appended, it would become easier for someone
+	to argue later that a "Signed-off-by" trailer was just added
+	out of habit or by automation, without the committer's full
+	awareness or intent to certify their agreement with the
+	Developer Certificate of Origin (DCO) or a similar statement.
+	This could undermine the sign-off’s credibility in legal or
+	contractual situations.
++
+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.
+
+
 Credentials
 -----------
 
diff --git c/Documentation/signoff-option.adoc w/Documentation/signoff-option.adoc
index cddfb225d1..9a80d60f1b 100644
--- c/Documentation/signoff-option.adoc
+++ w/Documentation/signoff-option.adoc
@@ -16,3 +16,7 @@ endif::git-commit[]
 +
 The `--no-signoff` option can be used to countermand an earlier `--signoff`
 option on the command line.
++
+Git does not (and will not) have a configuration variable to enable
+the `--signoff` command line option by default; see the
+`commit.signoff` entry in the gitfaq for more details.

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Elijah Newren]

On Tue, Dec 16, 2025 at 10:54 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Every now and then we see this coming up on the list.  Let's help
> new contributors who are not aware of past discussions by clearly
> documenting our past consensus.
>
> Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
> Helped-by: Elijah Newren <newren@gmail.com>
> Helped-by: Johannes Sixt <j6t@kdbg.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * The text is from Elijah and Johannes this round; I am merely
>    playing a copybot.

The text was derived from what you wrote, though...

>  Documentation/gitfaq.adoc         | 19 +++++++++++++++++++
>  Documentation/signoff-option.adoc |  4 ++++
>  2 files changed, 23 insertions(+)
>
> diff --git c/Documentation/gitfaq.adoc w/Documentation/gitfaq.adoc
> index f2917d142c..0e40befb77 100644
> --- c/Documentation/gitfaq.adoc
> +++ w/Documentation/gitfaq.adoc
> @@ -83,6 +83,25 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
>  which quotes the filename with spaces and specifies the `--nofork` option to
>  avoid backgrounding the process.
>
> +[[sign-off]]
> +Why not have `commit.signoff` and other configuration variables?::
> +       Git intentionally does not (and will not) provide a
> +       configuration variable, such as `commit.signoff`, to
> +       automatically add `--signoff` by default.  The reason is to
> +       protect the legal and intentional significance of a sign-off.
> +       If there were more automated and widely publicized ways for
> +       sign-offs to be appended, it would become easier for someone
> +       to argue later that a "Signed-off-by" trailer was just added
> +       out of habit or by automation, without the committer's full
> +       awareness or intent to certify their agreement with the
> +       Developer Certificate of Origin (DCO) or a similar statement.
> +       This could undermine the sign-off’s credibility in legal or
> +       contractual situations.
> ++
> +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.
> +
> +
>  Credentials
>  -----------
>
> diff --git c/Documentation/signoff-option.adoc w/Documentation/signoff-option.adoc
> index cddfb225d1..9a80d60f1b 100644
> --- c/Documentation/signoff-option.adoc
> +++ w/Documentation/signoff-option.adoc
> @@ -16,3 +16,7 @@ endif::git-commit[]
>  +
>  The `--no-signoff` option can be used to countermand an earlier `--signoff`
>  option on the command line.
> ++
> +Git does not (and will not) have a configuration variable to enable
> +the `--signoff` command line option by default; see the
> +`commit.signoff` entry in the gitfaq for more details.

I like Johannes' edits to the text I had; this commit looks good to me.

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

> I like Johannes' edits to the text I had; this commit looks good to me.

If you liked the final result, it probably should not matter much,
but I cannot tell if you are (obliquely) pointing out that I failed
to grab and apply Johannes's edit or if you are doubly agreeing with
the resulting text in the message you are responding to.

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Elijah Newren]

On Tue, Dec 16, 2025 at 8:47 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > I like Johannes' edits to the text I had; this commit looks good to me.
>
> If you liked the final result, it probably should not matter much,
> but I cannot tell if you are (obliquely) pointing out that I failed
> to grab and apply Johannes's edit or if you are doubly agreeing with
> the resulting text in the message you are responding to.

Um, I read Johannes' suggested edit and this patch and thought they
matched.  I just re-read them now, and don't see any edits that you
missed.  Am I missing something in his email, or another email of his?

Anyway, sorry, I guess I should have inserted a "so" right after the
semicolon ("...had; so, this commit looks good to me.)"

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Johannes Sixt]

Am 16.12.25 um 19:54 schrieb Junio C Hamano:
> Every now and then we see this coming up on the list.  Let's help
> new contributors who are not aware of past discussions by clearly
> documenting our past consensus.
> 
> Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
> Helped-by: Elijah Newren <newren@gmail.com>
> Helped-by: Johannes Sixt <j6t@kdbg.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * The text is from Elijah and Johannes this round; I am merely
>    playing a copybot.
> 
>  Documentation/gitfaq.adoc         | 19 +++++++++++++++++++
>  Documentation/signoff-option.adoc |  4 ++++
>  2 files changed, 23 insertions(+)
> 
> diff --git c/Documentation/gitfaq.adoc w/Documentation/gitfaq.adoc
> index f2917d142c..0e40befb77 100644
> --- c/Documentation/gitfaq.adoc
> +++ w/Documentation/gitfaq.adoc
> @@ -83,6 +83,25 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`,
>  which quotes the filename with spaces and specifies the `--nofork` option to
>  avoid backgrounding the process.
>  
> +[[sign-off]]
> +Why not have `commit.signoff` and other configuration variables?::
> +	Git intentionally does not (and will not) provide a
> +	configuration variable, such as `commit.signoff`, to
> +	automatically add `--signoff` by default.  The reason is to
> +	protect the legal and intentional significance of a sign-off.
> +	If there were more automated and widely publicized ways for
> +	sign-offs to be appended, it would become easier for someone
> +	to argue later that a "Signed-off-by" trailer was just added
> +	out of habit or by automation, without the committer's full
> +	awareness or intent to certify their agreement with the
> +	Developer Certificate of Origin (DCO) or a similar statement.
> +	This could undermine the sign-off’s credibility in legal or
> +	contractual situations.
> ++
> +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.

I feel that we should s/pile on/pile/, but I am not a native speaker.

This patch looks good with or without this change.

> +
> +
>  Credentials
>  -----------
>  
> diff --git c/Documentation/signoff-option.adoc w/Documentation/signoff-option.adoc
> index cddfb225d1..9a80d60f1b 100644
> --- c/Documentation/signoff-option.adoc
> +++ w/Documentation/signoff-option.adoc
> @@ -16,3 +16,7 @@ endif::git-commit[]
>  +
>  The `--no-signoff` option can be used to countermand an earlier `--signoff`
>  option on the command line.
> ++
> +Git does not (and will not) have a configuration variable to enable
> +the `--signoff` command line option by default; see the
> +`commit.signoff` entry in the gitfaq for more details.

-- Hannes

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

>> +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.
>
> I feel that we should s/pile on/pile/, but I am not a native speaker.
>
> This patch looks good with or without this change.

Thanks.  "add more mistakes" should be clear for everybody, so I'll
change the verb.

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Kristoffer Haugsbakk]

On Tue, Dec 16, 2025, at 19:54, Junio C Hamano wrote:
>[snip]
> ++
> +Git does not (and will not) have a configuration variable to enable
> +the `--signoff` command line option by default; see the
> +`commit.signoff` entry in the gitfaq for more details.

This is in `next` now but:

s/the gitfaq/in linkgit:gitfaq[7]/

Re: [PATCH v2] commit: document that $command.signoff will not be added

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Tue, Dec 16, 2025, at 19:54, Junio C Hamano wrote:
>>[snip]
>> ++
>> +Git does not (and will not) have a configuration variable to enable
>> +the `--signoff` command line option by default; see the
>> +`commit.signoff` entry in the gitfaq for more details.
>
> This is in `next` now but:
>
> s/the gitfaq/in linkgit:gitfaq[7]/

Thanks.