Re: Enabling scissors by default?

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Enabling scissors by default?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:55:41

Phillip Susi [off-list ref] writes:
On 01/08/2013 05:42 PM, Junio C Hamano wrote:
quoted
It is very easy to miss misidentification of scissors line; as a 
dangerous, potentially information losing option, I do not think
it should be on by default.
I suppose if it only requires one instance of >8 or <8 and one -, it
might be *slightly* dangerous, but if it required a slightly longer
minimum line length, it would be pretty darn unlikely to get triggered
by accident, and of course, is easily disabled.
"Easily disabled" is never a good enough reason to change the long
established default of not doing anything funky unless the user
explicitly asks it to do things differently.

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

Re: Enabling scissors by default?

From: Jeff King <hidden>
Date: 2016-06-15 22:55:42

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

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help