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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html