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

[Chris Down <chris@chrisdown.name>]

[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.