Hi Jonathan, On Thu, Jun 02, 2011 at 00:53:57, Jonathan Nieder wrote: > 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? Well, it is required to keep track of who was in the upstream path. This way all relevant folks can be contacted in case the patch introduces a problem. > > 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)? Okay, here is the issue that prompted me to work on this: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-May/022832.html I think this option is useful for maintainers who usually do not apply patches en-masse, but accept patches after review and want to pass along to other upstream maintainers after adding their sign-off. Granted you can always rely on -s option to be added, but people do forget (like I did). > > 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. If you received any patch with a sign-off, I think it is usually safe to attach your own sign-off since then the origin of the patch is already certified by someone else (you would be adding your sign-off under Developer's Certificate of Origin 1.1 section (c)) Thanks, Sekhar -- 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