git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] commit: Add commit.signoff configuration option

From
Chris Down <chris@chrisdown.name>
Date
May 14, 2025, 16:46 UTC
Message-ID
<aCTI7VjK5QMht3ws@chrisdown.name>
In-Reply-To
<CALnO6CBdhYFsDN=HPo9HbKeoZH7bb=xVVXUCK7nUdadLg-U_Pw@mail.gmail.com>
[Code changes acked, thank you for the review :-)]
D. Ben Knoble writes:
>It would probably be nice to say why this makes sense in light of
>previously-raised objections, too [1].
>
>[1]: https://lore.kernel.org/git/xmqqo6x4p6z2.fsf@gitster.g/

I understand where people are coming from for sure, but I think the conversation has moved on beyond many of those points, right? For example, some of the objections are about format.signoff in 2006, but we merged that into the tree since 2009 in commit 1d1876e9300c ("Add configuration variable for sign-off to format-patch").

 From those threads, the main arguments seem to be:
- Signoff should be a conscious act
- Adding it automatically might dilute its meaning
- The potential for signoffs through inertia without proper intent
However, I think these objections don't hold up well in light of a few things.

First, the objections conflict with precedent from the now merged format.signoff. If we've already determined that configuring automatic signoffs in one context is acceptable (where that will then later become a commit anyway), it creates inconsistency to reject the same capability in another closely related context.

Second, setting a configuration value _is_ a conscious act. When I enable commit.signoff=true in a repository, I'm making a deliberate, repository specific declaration that I have the rights to submit all work in this repository under the project's license. This is arguably even more meaningful than mechanically adding -s to individual commits, either without thought through muscle memory, or through a shell based, context agnostic alias as many users do now.

In general, it feels like an inconsistency in semantics to have format.signoff available but not commit.signoff. From a user's perspective, we're just adding a signoff trailer to something that will eventually become an upstream commit. It doesn't really matter whether that's through a mailing list (format-patch), a pull request (commit), or otherwise.

I'm certainly open to further discussion, of course, but the existing precedent seems to make a compelling case for this feature.

Previous: D. Ben KnobleNext: Junio C Hamano
Message 4 of 14 in “commit: Add commit.signoff configuration option”
  1. commit: Add commit.signoff configuration optionChris Down, May 13, 2025
  2. Kristoffer HaugsbakkMay 13, 2025
  3. D. Ben KnobleMay 13, 2025
  4. Chris DownMay 14, 2025
  5. Junio C HamanoMay 15, 2025
  6. Chris DownMay 15, 2025
  7. Junio C HamanoMay 16, 2025
  8. Chris DownMay 16, 2025
  9. Chris DownJun 3, 2025
  10. Junio C HamanoJun 4, 2025
  11. Collin FunkJun 5, 2025
  12. Chris DownJun 9, 2025
  13. Ben KnobleMay 16, 2025
  14. Chris DownMay 16, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.