On Tue, Jan 08, 2013 at 03:36:09PM -0800, Junio C Hamano wrote: > You could introduce a new configuration variable "am.scissors" and > personally turn it on, though. Setting that variable *does* count > as the user explicitly asking for it. I think we have mailinfo.scissors already. > > I often see patches being tweaked in response to feedback and > > resubmitted, usually with a description of what has changed since the > > previous version. Such descriptions don't need to be in the change > > log when it is finally applied and seem a perfect use of scissors. > > Putting such small logs under "---" line is the accepted practice. Maybe it is just me, but I find the scissors form more readable, because the "cover letter" material often serves to introduce and give context to the patch (e.g., "Thanks for your feedback. I've tried to do X, and it came out well. Here's the patch." serves as an introduction, and logically comes before the commit message itself). That does not say anything one way or another about how dangerous or not it might be to enable scissors by default. Just my two cents that I like the scissors style for patches that come as part of a discussion (and I prefer the "---" style when making comments on the contents of a patch; i.e., when the comments make more sense to be read after reading the commit message to understand what the patch does). -Peff -- 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