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