Jeff King <peff@xxxxxxxx> writes: > 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. Oh, spoiler. I was hoping that I could entice new people into doing a little digging on their own X-<. >> > 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). Yes, scissors have their uses, namely when presenting a patch in a discussion context. Otherwise we wouldn't have introduced it in the first place. But the "desription of what has changed since the previous version" use case I was responding to is where the space below "---" is meant to be used from very early days of Git (the convention established on the kernel list). -- 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