Re: Enabling scissors by default?

Jeff King [off-list ref] writes:

On Tue, Jan 08, 2013 at 03:36:09PM -0800, Junio C Hamano wrote:

quoted

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-<.

quoted

quoted

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).