Re: [PATCH 1/1] git-am: provide configuration to enable signoff by default

[Jonathan Nieder <jrnieder@gmail.com>]

Nori, Sekhar wrote:
> On Wed, Jun 01, 2011 at 22:44:30, Junio C Hamano wrote:

>> Also if it doesn't have to be a conscious act, what value does such a
>> boilerplate have? Such a project may be better off not using sign-off at
>> all to begin with.
>
> Its hard to argue against this. All I would say is it is probably
> much safer to enable sign off by default when accepting a patch
> than when preparing to send it. Yet, we have format.signoff but
> no am.signoff. On any project with conscious sign-off rules, one
> would never accept a patch without a sign-off from the original
> developer.

In that case, just the first sign-off should be enough and there is no
need to record the later ones, no?

In practice, with format.signoff hopefully people read the patches
they are sending out before mailing them.  It is very easy to remove
the sign-off in an MUA or by editing patch files before running
"git send-email" if it was inappropriate.  On the contrary, importing
patches en masse with "git am" is a common operation and I suspect
looking over the new history in detail before a "git push" is rare, so
the possibility of someone forgetting that an "[am] signOff" variable
is in effect is much more dangerous.

That said, I am all for giving people rope as long as there is some
legitimate use case documented to explain how not to hang themselves.
Could you say more about the example that motivated this?  What
benefit would this provide to motivate not using "git am -3sc" (which
contains the -s on the commandline as a reminder)?

> So, just making it easier to accept patches which are already
> signed-off should be okay, I guess?

A related idea seems interesting: would a --check-sign-off option that
prevents applying a patch unless the last sign-off matches the email
sender be useful?  Unfortunately individual people sometimes use
different addresses for the From and Signed-off-by lines in some
projects (like git and the Linux kernel) so I don't think I'd use such
a thing but in a more controlled environment I can imagine it might be
nice.

Thanks.

Sorry for the longwinded message; still, hope that helps.

Regards,
Jonathan