Re: Enabling scissors by default?

[Jeff King <peff@peff.net>]

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