git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH] Doc: note minimum scissors line length for mailinfo
@ 2020-09-25 19:16 Evan Gates
  2020-09-28 18:35 ` jrnieder
  2020-09-28 20:20 ` [PATCH v2] Doc: specify exact scissors line Evan Gates
  0 siblings, 2 replies; 10+ messages in thread
From: Evan Gates @ 2020-09-25 19:16 UTC (permalink / raw)
  To: git

There is a comment in is_scissors_line describing the requirements for
a line to be considered a scissors line.  While the existing wording
covers most of the requirements, there was no mention of minimum size.

Signed-off-by: Evan Gates <evan.gates@gmail.com>
---
This comes up after I tried to use --8<-- as scissors but git am didn't
recognize it because it's only 6 bytes.  I couldn't figure out why until
I cloned git and checked the source.

I am not subscribed to the list, please cc me in any replies.

 Documentation/git-mailinfo.txt | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 3bbc731f67..859829d32f 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -74,11 +74,11 @@ conversion, even with this flag.
 --scissors::
 	Remove everything in body before a scissors line.  A line that
 	mainly consists of scissors (either ">8" or "8<") and perforation
-	(dash "-") marks is called a scissors line, and is used to request
-	the reader to cut the message at that line.  If such a line
-	appears in the body of the message before the patch, everything
-	before it (including the scissors line itself) is ignored when
-	this option is used.
+	(dash "-") marks and is at least 8 bytes long ("-- >8 --") is
+	called a scissors line, and is used to request the reader to cut
+	the message at that line.  If such a line appears in the body
+	of the message before the patch, everything before it (including
+	the scissors line itself) is ignored when this option is used.
 +
 This is useful if you want to begin your message in a discussion thread
 with comments and suggestions on the message you are responding to, and to
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] Doc: note minimum scissors line length for mailinfo
  2020-09-25 19:16 [PATCH] Doc: note minimum scissors line length for mailinfo Evan Gates
@ 2020-09-28 18:35 ` jrnieder
  2020-09-28 18:55   ` Junio C Hamano
  2020-09-28 20:20 ` [PATCH v2] Doc: specify exact scissors line Evan Gates
  1 sibling, 1 reply; 10+ messages in thread
From: jrnieder @ 2020-09-28 18:35 UTC (permalink / raw)
  To: Evan Gates; +Cc: git

Hi,

Evan Gates wrote:

> There is a comment in is_scissors_line describing the requirements for
> a line to be considered a scissors line.  While the existing wording
> covers most of the requirements, there was no mention of minimum size.
>
> Signed-off-by: Evan Gates <evan.gates@gmail.com>
> ---
> This comes up after I tried to use --8<-- as scissors but git am didn't
> recognize it because it's only 6 bytes.  I couldn't figure out why until
> I cloned git and checked the source.

Thanks for following through.  It's probably worth mentioning this
example ("--8<--") in the commit message as well.

[...]
> --- a/Documentation/git-mailinfo.txt
> +++ b/Documentation/git-mailinfo.txt
> @@ -74,11 +74,11 @@ conversion, even with this flag.
>  --scissors::
>  	Remove everything in body before a scissors line.  A line that
>  	mainly consists of scissors (either ">8" or "8<") and perforation
> -	(dash "-") marks is called a scissors line, and is used to request
> -	the reader to cut the message at that line.  If such a line
> -	appears in the body of the message before the patch, everything
> -	before it (including the scissors line itself) is ignored when
> -	this option is used.
> +	(dash "-") marks and is at least 8 bytes long ("-- >8 --") is

nit: I think "characters" instead of "bytes" would focus a bit more on
the intent.  It's true that characters and bytes coincide in this
example, but using characters might be a bit more in the terms that
the user is already thinking in.

By the way, is this the right criterion?  Perhaps an alternative
method would be to make "--8<--" count as a scissors like after all.
What do you think?

> +	called a scissors line, and is used to request the reader to cut
> +	the message at that line.  If such a line appears in the body
> +	of the message before the patch, everything before it (including
> +	the scissors line itself) is ignored when this option is used.
>  +
>  This is useful if you want to begin your message in a discussion thread
>  with comments and suggestions on the message you are responding to, and to

With the commit message and wording tweaks listed above,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Doc: note minimum scissors line length for mailinfo
  2020-09-28 18:35 ` jrnieder
@ 2020-09-28 18:55   ` Junio C Hamano
  2020-09-28 19:00     ` Jonathan Nieder
  0 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2020-09-28 18:55 UTC (permalink / raw)
  To: jrnieder; +Cc: Evan Gates, git

jrnieder@gmail.com writes:

>> +	(dash "-") marks and is at least 8 bytes long ("-- >8 --") is
>
> nit: I think "characters" instead of "bytes" would focus a bit more on
> the intent.  It's true that characters and bytes coincide in this
> example, but using characters might be a bit more in the terms that
> the user is already thinking in.
>
> By the way, is this the right criterion?  Perhaps an alternative
> method would be to make "--8<--" count as a scissors like after all.
> What do you think?

Mildly negative.

It certainly was fun to declare that users can use anything that
look like perforation drawn on paper, and to pile more and more
heuristics to detect such a line.  But I think, instead of
describing all these details in the manual, telling the users to
always write "-- >8 --" and nothing else would be a better approach.

It would save them time.

Let's not waste people's time by encouraging them to be "creative"
in areas that do not make the world a better place.  How flexible
they can be when drawing the line to mark the part that recipent
can discard does not matter in the end result of their work.

Thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Doc: note minimum scissors line length for mailinfo
  2020-09-28 18:55   ` Junio C Hamano
@ 2020-09-28 19:00     ` Jonathan Nieder
  2020-09-28 19:20       ` Evan Gates
  0 siblings, 1 reply; 10+ messages in thread
From: Jonathan Nieder @ 2020-09-28 19:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Evan Gates, git

Junio C Hamano wrote:

> It certainly was fun to declare that users can use anything that
> look like perforation drawn on paper, and to pile more and more
> heuristics to detect such a line.  But I think, instead of
> describing all these details in the manual, telling the users to
> always write "-- >8 --" and nothing else would be a better approach.
>
> It would save them time.

Agreed, I think this is a much better direction.

Another advantage is that it makes us easier to change the heuristics,
confident that we are training users to aim for the simple and
reliable case instead of the edge cases that may need to be tweaked
over time.

Thanks,
Jonathan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Doc: note minimum scissors line length for mailinfo
  2020-09-28 19:00     ` Jonathan Nieder
@ 2020-09-28 19:20       ` Evan Gates
  2020-09-28 19:33         ` Kevin Daudt
  0 siblings, 1 reply; 10+ messages in thread
From: Evan Gates @ 2020-09-28 19:20 UTC (permalink / raw)
  To: Jonathan Nieder, Junio C Hamano; +Cc: git

On Mon Sep 28, 2020 at 12:00 PM PDT, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > It certainly was fun to declare that users can use anything that
> > look like perforation drawn on paper, and to pile more and more
> > heuristics to detect such a line.  But I think, instead of
> > describing all these details in the manual, telling the users to
> > always write "-- >8 --" and nothing else would be a better approach.
> >
> > It would save them time.
>
> Agreed, I think this is a much better direction.
>
> Another advantage is that it makes us easier to change the heuristics,
> confident that we are training users to aim for the simple and
> reliable case instead of the edge cases that may need to be tweaked
> over time.

Sounds good to me.  How about:

Remove everything in body before a scissors line ("-- >8 --"). The line
represents scissors and perforation marks, and is used to request the
reader to cut the message at that line.  If that line appears in the
body of the message before the patch, everything before it (including
the scissors line itself) is ignored when this option is used.

Etiquette question: Should a v2 patch be a new thread or reply to
this one?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] Doc: note minimum scissors line length for mailinfo
  2020-09-28 19:20       ` Evan Gates
@ 2020-09-28 19:33         ` Kevin Daudt
  0 siblings, 0 replies; 10+ messages in thread
From: Kevin Daudt @ 2020-09-28 19:33 UTC (permalink / raw)
  To: Evan Gates; +Cc: Jonathan Nieder, Junio C Hamano, git

On Mon, Sep 28, 2020 at 12:20:31PM -0700, Evan Gates wrote:
> On Mon Sep 28, 2020 at 12:00 PM PDT, Jonathan Nieder wrote:
> > Junio C Hamano wrote:
> >
> > > It certainly was fun to declare that users can use anything that
> > > look like perforation drawn on paper, and to pile more and more
> > > heuristics to detect such a line.  But I think, instead of
> > > describing all these details in the manual, telling the users to
> > > always write "-- >8 --" and nothing else would be a better approach.
> > >
> > > It would save them time.
> >
> > Agreed, I think this is a much better direction.
> >
> > Another advantage is that it makes us easier to change the heuristics,
> > confident that we are training users to aim for the simple and
> > reliable case instead of the edge cases that may need to be tweaked
> > over time.
> 
> Sounds good to me.  How about:
> 
> Remove everything in body before a scissors line ("-- >8 --"). The line
> represents scissors and perforation marks, and is used to request the
> reader to cut the message at that line.  If that line appears in the
> body of the message before the patch, everything before it (including
> the scissors line itself) is ignored when this option is used.
> 
> Etiquette question: Should a v2 patch be a new thread or reply to
> this one?

Typically you would reply to this thread, ie, to
20200925191659.31375-1-evan.gates@gmail.com

Kevin

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v2] Doc: specify exact scissors line
  2020-09-25 19:16 [PATCH] Doc: note minimum scissors line length for mailinfo Evan Gates
  2020-09-28 18:35 ` jrnieder
@ 2020-09-28 20:20 ` Evan Gates
  2020-09-28 22:31   ` Junio C Hamano
  2020-09-28 22:51   ` [PATCH v3] Doc: show example " Evan Gates
  1 sibling, 2 replies; 10+ messages in thread
From: Evan Gates @ 2020-09-28 20:20 UTC (permalink / raw)
  To: git

The existing wording covers most of the requirements of a scissors
line, but there is no mention of the minimum size requirement that led
to a six character line ("-->8--") not counting as a scissors line.
Specify the exact line to use ("-- >8 --") instead of trying to document
all the details.

Signed-off-by: Evan Gates <evan.gates@gmail.com>
---
Changes in v2:
- Specify exact line instead of adding text about 8 character minimum

 Documentation/git-mailinfo.txt | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 3bbc731f67..fbb7d2813f 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -72,10 +72,9 @@ conversion, even with this flag.
 	is useful in order to associate commits with mailing list discussions.
 
 --scissors::
-	Remove everything in body before a scissors line.  A line that
-	mainly consists of scissors (either ">8" or "8<") and perforation
-	(dash "-") marks is called a scissors line, and is used to request
-	the reader to cut the message at that line.  If such a line
+	Remove everything in body before a scissors line ("-- >8 --").
+	The line represents scissors and perforation marks, and is used to
+	request the reader to cut the message at that line.  If that line
 	appears in the body of the message before the patch, everything
 	before it (including the scissors line itself) is ignored when
 	this option is used.
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] Doc: specify exact scissors line
  2020-09-28 20:20 ` [PATCH v2] Doc: specify exact scissors line Evan Gates
@ 2020-09-28 22:31   ` Junio C Hamano
  2020-09-28 22:51   ` [PATCH v3] Doc: show example " Evan Gates
  1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2020-09-28 22:31 UTC (permalink / raw)
  To: Evan Gates; +Cc: git

Evan Gates <evan.gates@gmail.com> writes:

> The existing wording covers most of the requirements of a scissors
> line, but there is no mention of ...
> ...
> Specify the exact line to use ("-- >8 --") instead of trying to document
> all the details.

s/most/some/;

For example, the code has fun heuristics to understand that things
like "-- >8 ---- >8 -- cut here -- >8 ---- >8 --" is a scissors
line, but we do not document it.

But what we agreed is that it is a bad idea to even attempt to
describe the heuristics down to the details and sell the feature as
"we accept anything that resembles a perforation drawn or printed on
paper".  Instead we are giving less choices to make it easier for
users to follow, and the updated text is a move in that direction.

So selling this change based on "the existing description does not
give enough" is not good.

    The text tries to say the code accepts many variations that
    looks remotely like scissors and perforation line, but gives too
    little detail for users to decide what is and what is not taken
    as a scissors line for themselves.  Instead of describing the
    heuristics more, just spell out what will always be accepted,
    namely "-- >8 --", as it would not help users to give them more
    choices and flexibility and be "creative" in their scissors
    line.

perhaps?

> Signed-off-by: Evan Gates <evan.gates@gmail.com>
> ---
> Changes in v2:
> - Specify exact line instead of adding text about 8 character minimum
>
>  Documentation/git-mailinfo.txt | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
> index 3bbc731f67..fbb7d2813f 100644
> --- a/Documentation/git-mailinfo.txt
> +++ b/Documentation/git-mailinfo.txt
> @@ -72,10 +72,9 @@ conversion, even with this flag.
>  	is useful in order to associate commits with mailing list discussions.
>  
>  --scissors::
> +	Remove everything in body before a scissors line ("-- >8 --").
> +	The line represents scissors and perforation marks, and is used to
> +	request the reader to cut the message at that line.  If that line

We want to say "e.g.", i.e. 'a scissors line (e.g. "-- >8 --")', in
order to hint that we may accept other forms [*1*], and also to hint
that we do not want to go int details.

Other than that, I like the conciseness of the updated text.


[Footnote]
*1* This is primarily to be friendly to left-handers to let them
write "-- 8< --".

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v3] Doc: show example scissors line
  2020-09-28 20:20 ` [PATCH v2] Doc: specify exact scissors line Evan Gates
  2020-09-28 22:31   ` Junio C Hamano
@ 2020-09-28 22:51   ` Evan Gates
  2020-09-28 23:41     ` Junio C Hamano
  1 sibling, 1 reply; 10+ messages in thread
From: Evan Gates @ 2020-09-28 22:51 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

The text tries to say the code accepts many variations that look remotely
like scissors and perforation marks, but gives too little detail for users
to decide what is and what is not taken as a scissors line for themselves.
Instead of describing the heuristics more, just spell out what will always
be accepted, namely "-- >8 --", as it would not help users to give them
more choices and flexibility and be "creative" in their scissors line.

Signed-off-by: Evan Gates <evan.gates@gmail.com>
---
Changes in v3:
- Reword commit message to better explain intent
- Add "e.g." to hint at other forms

Changes in v2:
- Specify exact line instead of adding text about 8 character minimum

 Documentation/git-mailinfo.txt | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 3bbc731f67..7a6aed0e30 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -72,10 +72,9 @@ conversion, even with this flag.
 	is useful in order to associate commits with mailing list discussions.
 
 --scissors::
-	Remove everything in body before a scissors line.  A line that
-	mainly consists of scissors (either ">8" or "8<") and perforation
-	(dash "-") marks is called a scissors line, and is used to request
-	the reader to cut the message at that line.  If such a line
+	Remove everything in body before a scissors line (e.g. "-- >8 --").
+	The line represents scissors and perforation marks, and is used to
+	request the reader to cut the message at that line.  If that line
 	appears in the body of the message before the patch, everything
 	before it (including the scissors line itself) is ignored when
 	this option is used.
-- 
2.28.0


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH v3] Doc: show example scissors line
  2020-09-28 22:51   ` [PATCH v3] Doc: show example " Evan Gates
@ 2020-09-28 23:41     ` Junio C Hamano
  0 siblings, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2020-09-28 23:41 UTC (permalink / raw)
  To: Evan Gates; +Cc: git

Thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-09-28 23:41 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25 19:16 [PATCH] Doc: note minimum scissors line length for mailinfo Evan Gates
2020-09-28 18:35 ` jrnieder
2020-09-28 18:55   ` Junio C Hamano
2020-09-28 19:00     ` Jonathan Nieder
2020-09-28 19:20       ` Evan Gates
2020-09-28 19:33         ` Kevin Daudt
2020-09-28 20:20 ` [PATCH v2] Doc: specify exact scissors line Evan Gates
2020-09-28 22:31   ` Junio C Hamano
2020-09-28 22:51   ` [PATCH v3] Doc: show example " Evan Gates
2020-09-28 23:41     ` Junio C Hamano

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).