[PATCH] send-email: do not prompt for In-Reply-To

[PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

Most mailing lists prefer that new patchsets and their revisions are
placed into a new thread. Additionally, knowledge of what In-Reply-To
means and where to find the Message-Id to fill in are domain-specific
and confusing to new users. In the niche situations where this is called
for, the --in-reply-to flag is sufficient.

A config option, sendemail.promptInReplyTo, has been added to re-enable
the old behavior.
---
 Documentation/config/sendemail.txt | 7 +++++++
 git-send-email.perl                | 5 ++++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt
index cbc5af42fd..34ca8263d0 100644
--- a/Documentation/config/sendemail.txt
+++ b/Documentation/config/sendemail.txt
@@ -66,3 +66,10 @@ sendemail.forbidSendmailVariables::
 	To avoid common misconfiguration mistakes, linkgit:git-send-email[1]
 	will abort with a warning if any configuration options for "sendmail"
 	exist. Set this variable to bypass the check.
+
+sendemail.promptInReplyTo::
+	Previous versions of linkgit:git-send-email[1] would prompt the user to
+	input an In-Reply-To header for every patchset sent. This was removed as
+	the default behavior, being generally undesirable on most mailing lists,
+	and confusing for new users. Set this variable to re-enable the old
+	behavior.
diff --git a/git-send-email.perl b/git-send-email.perl
index 1f425c0809..f3abccef6d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -251,6 +251,7 @@ sub do_edit {
 my $validate = 1;
 my $target_xfer_encoding = 'auto';
 my $forbid_sendmail_variables = 1;
+my $prompt_in_reply_to = 0;
 
 my %config_bool_settings = (
     "thread" => \$thread,
@@ -265,6 +266,7 @@ sub do_edit {
     "annotate" => \$annotate,
     "xmailer" => \$use_xmailer,
     "forbidsendmailvariables" => \$forbid_sendmail_variables,
+    "promptinreplyto" => \$prompt_in_reply_to,
 );
 
 my %config_settings = (
@@ -467,6 +469,7 @@ sub read_config {
 		    "batch-size=i" => \$batch_size,
 		    "relogin-delay=i" => \$relogin_delay,
 		    "git-completion-helper" => \$git_completion_helper,
+		    "prompt-in-reply-to" => \$prompt_in_reply_to,
 	 );
 
 # Munge any "either config or getopt, not both" variables
@@ -978,7 +981,7 @@ sub expand_one_alias {
 @initial_cc = process_address_list(@initial_cc);
 @initial_bcc = process_address_list(@initial_bcc);
 
-if ($thread && !defined $initial_in_reply_to && $prompting) {
+if ($thread && !defined $initial_in_reply_to && $prompting && $prompt_in_reply_to) {
 	$initial_in_reply_to = ask(
 		__("Message-ID to be used as In-Reply-To for the first email (if any)? "),
 		default => "",
-- 
2.28.0

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

Drew DeVault <sir@cmpwn.com> writes:

> Most mailing lists prefer that new patchsets and their revisions are
> placed into a new thread. Additionally, knowledge of what In-Reply-To
> means and where to find the Message-Id to fill in are domain-specific
> and confusing to new users. In the niche situations where this is called
> for, the --in-reply-to flag is sufficient.
>
> A config option, sendemail.promptInReplyTo, has been added to re-enable
> the old behavior.

We do not break existing users' habits without a good reason, and a
subjective "this is the way I prefer" is *not* a good reason.

If/when the claim "most mailing lists prefer" can be substantiated,
we'd need to devise a transition plan to flip the default over
several releases.  Here is how I would envision the plan should go.

 (0) Introduce sendemail.promptInReplyTo that defaults to true; this
     can be done today and it would be a genuine improvement for
     those who want the new behaviour, without hurting any existing
     users.

 (1) Substantiate the "most mailing list prefer" claim.  If we
     cannot, we stop here.  Otherwise we would move to the next
     step.

 (2) Teach "git send-email" to issue a warning message when the
     telling the user that the default will be flipped in some
     future version of Git and optionally ask them to tell us to
     stop on the mailing list, when sendemail.promptInReplyTo
     configuration variable is not set.

     Advertise the future flip of the default in other channels,
     too.

 (3) Wait for at least a few releases.  Monitor the mailing list and
     other channels for objections, and if it becomes clear that we
     misjudged in step (1), stop the transition plan by reverting to
     the state before step (2) (i.e. not to before step (0)).

 (4) Flip the default and tweak the message to tell those users who
     still do not have sendemail.promptInReplyTo variable set that
     the default have changed, and if they want to get prompted,
     they must set the variable to true.  Also stop asking them to
     tell us to stop---at this point we are committed and will not
     go back.

 (5) Waiting for several releases

 (6) Remove the code to give messages for users who do not have the
     configuration variable.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Drew DeVault <sir@cmpwn.com> writes:
>
>> Most mailing lists prefer that new patchsets and their revisions are
>> placed into a new thread. Additionally, knowledge of what In-Reply-To
>> means and where to find the Message-Id to fill in are domain-specific
>> and confusing to new users. In the niche situations where this is called
>> for, the --in-reply-to flag is sufficient.
>>
>> A config option, sendemail.promptInReplyTo, has been added to re-enable
>> the old behavior.
>
> We do not break existing users' habits without a good reason, and a
> subjective "this is the way I prefer" is *not* a good reason.

Having said that (and I am not retracting anything I said in the
message I am responding to), I haven't seen this prompt triggering
for me when I use send-email, with or without --in-reply-to option
on the command line.

Admittedly I use a wrapper around "git send-email" to add minimum
set of command line options that are always used (they are --from,
--envelope-sender, and --smtp-server) but I do not think they have
effect on the use of in-reply-to prompt.  

What are we doing differently, I wonder?

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

Do you have sendemail.to set in your local git config?

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

Okay, thanks for the info! I'll take this back to the drawing board and
come up with a plan which follows more closely to that.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Carlo Marcelo Arenas Belón]

On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:
> Do you have sendemail.to set in your local git config?

I do and can't reproduce either; which version of git do you have this
problem with?

Carlo

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

"Drew DeVault" <sir@cmpwn.com> writes:

> Do you have sendemail.to set in your local git config?

Yes, and I'd assume most mailing list have a single to: address, and
people use a repository to interact with just a single project, so I
think it would be natural to have it in the per-repository
configuration file.  Is it true that you do not set it and that the
lack of the configuration is why you are getting prompted?

I suspect that it may not make much sense for the presense of
sendemail.to to affect prompting for other header fields (iow, my
not getting prompted might be a bug).

Thanks.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Thu Aug 27, 2020 at 3:21 PM EDT, Junio C Hamano wrote:
> Yes, and I'd assume most mailing list have a single to: address, and
> people use a repository to interact with just a single project, so I
> think it would be natural to have it in the per-repository
> configuration file. Is it true that you do not set it and that the
> lack of the configuration is why you are getting prompted?

No, this didn't make sense, I was mistaken. This shouldn't be the cause.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

I can reproduce both on git 2.28.0 and on github.com/git/git master.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Carlo Marcelo Arenas Belón]

On Thu, Aug 27, 2020 at 03:23:00PM -0400, Drew DeVault wrote:
> I can reproduce both on git 2.28.0 and on github.com/git/git master.

and you use --compose to send an email thread directly instead of
doing first `git-format-patch -o`?

Carlo

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:

> On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:
>> Do you have sendemail.to set in your local git config?
>
> I do and can't reproduce either; which version of git do you have this
> problem with?

Any recent version of git-send-email, I would say.  The relevant
code snippets are:

    my $prompting = 0;
    if (!@initial_to && !defined $to_cmd) {
            my $to = ask("$to_whom ",
                         default => "",
                         valid_re => qr/\@.*\./, confirm_only => 1);
            push @initial_to, parse_address_line($to) if defined $to; #
            $prompting++;
    }
    ...
    @initial_to = process_address_list(@initial_to);
    @initial_cc = process_address_list(@initial_cc);
    @initial_bcc = process_address_list(@initial_bcc);

    if ($thread && !defined $initial_in_reply_to && $prompting) {
            $initial_in_reply_to = ask(
                    __("Message-ID to be used as In-Reply-To for the first email (if any)? "),
                    default => "",
                    valid_re => qr/\@.*\./, confirm_only => 1);
    }

where initial_to is set either from the command line or sendemail.to
configuration variable and before the control reaches this section
of the code.  In addition to realizing "ah, To: address is not given
so we need to ask" and ask the to address, it says "since we have
already interatively asked the end-user anyway, we can and should
ask other things as well" by incrementing $prompting.

That feels both understandable and bogus at the same time.  To:
is pretty much required (yes, you can use cc: and bcc: without any
address on To:, but that is not something you'd usually do to send
patches to mailing lists), so lack of it means either asking
interactively or aborting.  But other things like in-reply-to are
optional, and tying the decision to prompt for them or not does not
feel OK.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

Do you think this whole workstream could be averted by dropping the
$prompting check in the in-reply-to branch?

Or would that still constitute a breaking change to user workflows?

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Carlo Arenas]

On Thu, Aug 27, 2020 at 12:35 PM Drew DeVault <sir@cmpwn.com> wrote:
> Do you think this whole workstream could be averted by dropping the
> $prompting check in the in-reply-to branch?
>
> Or would that still constitute a breaking change to user workflows?

I think the "breaking change" is changing the default (which needs
fixing as well).

but an interesting idea would be to add a config so the prompting
could be skipped which would be something that people could add to
their per repository config (as needed).

Carlo

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Carlo Marcelo Arenas Belón]

On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:
> 
> That feels both understandable and bogus at the same time.  To:
> is pretty much required (yes, you can use cc: and bcc: without any
> address on To:, but that is not something you'd usually do to send
> patches to mailing lists), so lack of it means either asking
> interactively or aborting.  But other things like in-reply-to are
> optional, and tying the decision to prompt for them or not does not
> feel OK.

but trying to "fix" this breaks 10 year old tests, so it is obvious
that everyone already expects it to work this way (probably hidden
by the fact most people don't let git-send-email prompt for "To:")

the patch after the scissors attempts to document the current "Legacy"
behaviour which should be worth doing regardless of what is done with
this patch.

but I suspect it might be worth adding a new configuration flag like
the one that was propossed so that the prompting could be set per
repository to either "Always" (for when forgetting it will break the
threads in lists that care, like this one) and "Never" (for when the
lists explicitally ask mails to be send without one, because they
use patchew or equivalent (ex: qemu-devel[1])).

Carlo

[1] https://wiki.qemu.org/Contribute/SubmitAPatch
--- >8 ---
Subject: [PATCH] send-email: document logic for In-Reply-To prompting

Eventhough there doesn't seem to be a good reason for it, it is
the way it has been implemented for the last 10 years.

Document the current behaviour (which the tests also depend on)
before it can be tweaked by a future per repository setting.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
---
 Documentation/git-send-email.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0a69810147..8e9ebb3fac 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -108,8 +108,7 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
       [PATCH v2 2/3] New tests
       [PATCH v2 3/3] Implementation
 +
-Only necessary if --compose is also set.  If --compose
-is not set, this will be prompted for.
+If --compose is not set, and there is no known "To:" this will be prompted for.
 
 --subject=<string>::
 	Specify the initial subject of the email thread.
-- 
2.28.0.424.gade71fd49b

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:

> On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:
>> 
>> That feels both understandable and bogus at the same time.  To:
>> is pretty much required (yes, you can use cc: and bcc: without any
>> address on To:, but that is not something you'd usually do to send
>> patches to mailing lists), so lack of it means either asking
>> interactively or aborting.  But other things like in-reply-to are
>> optional, and tying the decision to prompt for them or not does not
>> feel OK.
>
> but trying to "fix" this breaks 10 year old tests, so it is obvious
> that everyone already expects it to work this way (probably hidden
> by the fact most people don't let git-send-email prompt for "To:")

Oh, I agree with that 100%.

> -Only necessary if --compose is also set.  If --compose
> -is not set, this will be prompted for.
> +If --compose is not set, and there is no known "To:" this will be prompted for.

The updated sentence structure, with or without the mention of
"to:", reads much better than the original.  

The original told them that they must give it from the command line
in "--compose" mode, because they will not be given the chance to
give it interactively, and the intended target audience was those
who want to send a message with in-reply-to (which is natural, as
this is a description for that option).

The updated message says the same thing, but is audience-neutral and
tries to be more useful to folks who are not responding to any
message.  I.e. outside "--compose" mode, you'll be asked if you want
to make it a response, unless you gave "to:".

By losing the "we won't ask so you must give it from the command
line" message in the original, the resulting description has become
easier to follow, I think.  Those who do want to add the header,
when they reach this description in the manual, already knows that
there is a command line option.

To help those who do not want to add this header, it would probably
be more helpful to tell what to do when prompted (like "you can give
an empty answer to tell the command that you are not responding to
any message").

Thanks.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:
> To help those who do not want to add this header, it would probably
> be more helpful to tell what to do when prompted (like "you can give
> an empty answer to tell the command that you are not responding to
> any message").

I don't like this solution. We should make it harder to do the wrong
thing, and easier to do the right thing.

It would be helpful for git to take an opinionated stance on the right
way to send emails with it, since no one else is really in the position
to. This behavior has confused many people that I've spoken with and
makes for a rough introduction to a tool which people are already loathe
to learn. git send-email is really the best way to send emails with git,
and will save the user a lot of trouble in the future if they figure it
out, so I want it to be as easy to figure out as possible.

Even so, I understand the concerns raised so far. I haven't started on
v2 yet, but my rough plan is to add a config option along the lines of
sendemail.verbosePrompts, defaulted to on for now, which enables the
present-day behavior, along with a message stating the intention to
change the behavior in a future release, and an invitation to comment on
the mailing list.

The behavior of this flag if set to false would be equivalent to
removing the $prompting condition in the if statement which controls
whether or not this prompt is shown.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

Oh, and I should mention the fact that this breaking change is less
severe than we initially thought, only breaking an edge case - when --to
is not specified - so it's likely to have a pretty small impact. We'll
find out when someone emails us to complain, I suppose.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

"Drew DeVault" <sir@cmpwn.com> writes:

> On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:
>> To help those who do not want to add this header, it would probably
>> be more helpful to tell what to do when prompted (like "you can give
>> an empty answer to tell the command that you are not responding to
>> any message").
>
> I don't like this solution. We should make it harder to do the wrong
> thing, and easier to do the right thing.

Carlo and I were discussing how best to describe the behaviour we
have better to the users, which is unrelated to any code change that
would be required to "make it harder make it easier."  

We need to do so to help users in the meantime, before any behaviour
change (which need to happen over several releases, as outlined
earlier) happens.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Thu Aug 27, 2020 at 7:23 PM EDT, Junio C Hamano wrote:
> Carlo and I were discussing how best to describe the behaviour we
> have better to the users, which is unrelated to any code change that
> would be required to "make it harder make it easier."
>
> We need to do so to help users in the meantime, before any behaviour
> change (which need to happen over several releases, as outlined
> earlier) happens.

Ah, I see what you mean. I'll add some messaging like that in my v2, but
the point's likely moot anyway since I expect to have the patch ready
for the next release.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

"Drew DeVault" <sir@cmpwn.com> writes:

> Oh, and I should mention the fact that this breaking change is less
> severe than we initially thought, only breaking an edge case - when --to
> is not specified - so it's likely to have a pretty small impact. We'll
> find out when someone emails us to complain, I suppose.

I agree that it is likely that only very small population even gets
bittn by this "in-reply-to gets prompted" issue, because it is
unlikely for users not to give "to:" address in one way or another
and let the prompt logic to ask them.

Which means that it is OK to stop at step (0) in the long transition
sequence I outlined in a previous message from me.  

That is, introduce a configuration variable that can be set to 'no'
by those who do not want to be prompted for "in-reply-to:" when they
did not give "to:" and let the prompt logic to ask "to:", document
the variable well [*1*], and make sure the default behaviour when
the variable is not set is the same as now.

That way, we do not even need to debate if it is true that most
users do not want in-reply-to (i.e. step (1)).  That's the kind of
thing that is very hard to establish.

The minority who wants to use an updated behaviour can just set the
configuration once and the problem is behind them.  The minority who
wants to keep the current behaviour do not have to do anything.  And
there is no impact to the majority of people either way.

I hate having to go through a multi cycle compatibility-breaking
transition, because it would consume unnecessary resources from this
list (i.e. developer attention is the most scarce common resource
that must be shared across topics here), and we would avoid that
cost altogether because the affected population seems to be small
enough that it is not worth going through the rigmarole of flipping
the default.  That alone is a big plus.

It seems like we managed to cut down the scope quite a bit.  

Thanks.


[Footnote]

*1* As a part of "document the variable well", we can include a
message tweak for the prompt that asks for "in-reply-to:" to say
something like "if you never want to be prompted for in-reply-to:,
you can set this variable" when the variable is not set at all.
Those who did set the variable but still are getting the prompt are
explicitly opting into keeping the current behaviour by setting it
to 'yes', so they do not have to see that extra part of the message.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Thu Aug 27, 2020 at 9:02 PM EDT, Junio C Hamano wrote:
> The minority who wants to use an updated behaviour can just set the
> configuration once and the problem is behind them. The minority who
> wants to keep the current behaviour do not have to do anything. And
> there is no impact to the majority of people either way.

Eh, this would defeat the purpose. I hate the multi-cycle
compatibility-breaking dance as much as the next guy, but the whole
reason I'm here is to solve a real problem which noobs are encountering.
I on-board a lot of people with git-send-email and I've heard questions
and confusions over this prompt at least 10 times in the past few years.
Compatibility breakage is annoying but this is a real problem which real
users are having real difficulty with, and the demographic of affected
user may be particularly ill-equipped to deal with it on their own.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Raymond E. Pasco]

On Thu Aug 27, 2020 at 9:02 PM EDT, Junio C Hamano wrote:
> I agree that it is likely that only very small population even gets
> bittn by this "in-reply-to gets prompted" issue, because it is
> unlikely for users not to give "to:" address in one way or another
> and let the prompt logic to ask them.

The merits of this thread's proposal aside, send-email's prompting has
always seemed half-baked to me - it often doesn't even show up, and
doesn't prompt for some things that would be useful like additional CCs
(and if you're setting In-Reply-To, there are probably additional CCs).

The prompts have helped me not flub emails before, but arguably that's
not good since they're often not even shown and someone may come to rely
on their presence only to later accidentally turn them off.

Anyway, it's worth noting that, because the prompts *do* exist,
half-baked as they are, it's not really safe to assume that nobody sees
them. There might be a sizable population out there never specifying
"--to" because they know they'll be prompted for it.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Thu Aug 27, 2020 at 9:44 PM EDT, Raymond E. Pasco wrote:
> Anyway, it's worth noting that, because the prompts *do* exist,
> half-baked as they are, it's not really safe to assume that nobody sees
> them. There might be a sizable population out there never specifying
> "--to" because they know they'll be prompted for it.

I hardly ever use --to for one-off patches or repositories which I'm not
regularly contributing to, and I expect that prompt. In-Reply-To has a
much less compelling argument, though, as Junio pointed out, given that
it's often not necessary or desirable, whereas for "to", every email has
to have at least one recipient to make sense.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:
> To help those who do not want to add this header, it would probably
> be more helpful to tell what to do when prompted (like "you can give
> an empty answer to tell the command that you are not responding to
> any message").

I'm trying to come up with a message like this for a reduced-scope
initial patch, but I'm drawing up a blank when the goal is to avoid
confusing users who don't understand this. The goal is to remove
domain-specific knowledge about email, namely how the In-Reply-To and
Message-Id headers work, which is uncommon knowledge among new users.

"You can give an empty answer if you are not responding to any message"
could confuse users, because they might think -v2 is a "response", or
maybe they've written the patch in response to a discussion on the
-users mailing list, or any other number of reasons. Now they have to
figure out how to answer this prompt, even if the mailing list they're
sending it to isn't expecting it to be a reply. I came up with a number
of alternative wordings but they all ultimately failed to this same
problem.

In-Reply-To is such an arcane and tangental piece of knowledge so far
removed from git, and so little information is given to the user to help
them understand (1) what it is, and (2) whether they need it or not, and
(3) where to find it, that this prompt just seems totally awful to me.
It'd be like if we prompted someone to enter their display EDID when
filing a bug for a video game. Could it be useful? It's unlikely. Is the
user likely to know what the hell an EDID is? Almost certainly not!

"Legitimate" use-cases like qemu-devel or not, this is only ever going
to confuse new users, and I think that qemu is wrong for encouraging
users to deal with it.

Or they would be wrong, but I looked into it and, the qemu wiki advises
that the user does *not* use in-reply-to:

https://wiki.qemu.org/Contribute/SubmitAPatch

Nor does patchew make it easy to extract the message ID from their
interface for this use-case. I'm not sure where this qemu idea is coming
from.

Is compatibility-breaking migrations a nightmare? Well, maybe.

Is that nightmare worth such a trivial problem? Well, it seems trivial
to those of us who have been using it for years, but I can assure you
there are plenty of new users who shut down at this step.

I hate to be a nuisance over such a seemingly simple problem, but there
are a lot of new users who are struggling here and I care about their
struggle. What path should we take to fixing this issue for them?

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Raymond E. Pasco]

On Fri Aug 28, 2020 at 2:39 PM EDT, Drew DeVault wrote:
> "You can give an empty answer if you are not responding to any message"
> could confuse users, because they might think -v2 is a "response", or
> maybe they've written the patch in response to a discussion on the
> -users mailing list, or any other number of reasons. Now they have to
> figure out how to answer this prompt, even if the mailing list they're
> sending it to isn't expecting it to be a reply. I came up with a number
> of alternative wordings but they all ultimately failed to this same
> problem.

These *are* all reasons why a patch would be sent as a reply. You can
moderate your own lists however you like, but that does not mean that
patches being replies to other mails is 1) wrong or useless, or 2) not
in wide use. I wish the user experience were a bit smoother for those of
us who aren't dedicated Emacs manglers, but things like scissors lines
help a bit.

> "Legitimate" use-cases like qemu-devel or not, this is only ever going
> to confuse new users, and I think that qemu is wrong for encouraging
> users to deal with it.

qemu-devel was given by Carlo as an example of a list which does *not*
keep discussion together in threads; the example give of a list which
*does* keep things together in threads was the Git list itself (surely
the normative list for Git, if there is such a thing). It's too useful
to hackers (and presumably maintainers), I don't think anyone is going
to stop.

Looking at this in isolation from the polemics about list practices,
it's pretty clear that the way send-email prompts for things is not
logical. Axing the In-Reply-To prompt would be one way to make it
logical, because the only other prompt is the To prompt; this is removal
of a prompt users may expect, but by being so inconsistent, the software
itself already removes the prompt when I'm expecting it!

There may be other ways to make it logical, like having the appearance
of the In-Reply-To prompt depend solely on whether a message ID was
already provided or not (but since a message ID is not mandatory, it's
weird to prompt for it and not for, say, additional CCs).

Since every mail client I've ever seen has a "reply" button, I don't
think the concept of a reply is eldritch arcana that users must be
protected from. It's annoying to have to get a Message-ID and paste it,
sure. It would be nice if a mail client could do that for me (I think
dedicated Emacs manglers are insulated from this problem for that
reason). Probably whoever prompted for it in the first place just didn't
want to flub a message by leaving it out, which wouldn't be an issue for
a client command invoked as some variation on "reply all".

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

"Drew DeVault" <sir@cmpwn.com> writes:

> "You can give an empty answer if you are not responding to any message"
> could confuse users, because they might think -v2 is a "response", or
> maybe they've written the patch in response to a discussion on the
> -users mailing list, or any other number of reasons.

"Type the value you would have given to --in-reply-to command line
option (if you forgot to use it), or leave this field empty"
perhaps?  Those who do not know should be able to learn what
"--in-reply-to" is.  A prompt help is not the place to do a
documentation.

> I hate to be a nuisance over such a seemingly simple problem, but there
> are a lot of new users who are struggling here and I care about their
> struggle. What path should we take to fixing this issue for them?

The ideal way would be to craft step (0) well enough so that new
users trigger the To: prompt in the first place, which would
automatically make the problem disappear ;-)

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Fri Aug 28, 2020 at 5:00 PM EDT, Junio C Hamano wrote:
> "Drew DeVault" <sir@cmpwn.com> writes:
>
> > "You can give an empty answer if you are not responding to any message"
> > could confuse users, because they might think -v2 is a "response", or
> > maybe they've written the patch in response to a discussion on the
> > -users mailing list, or any other number of reasons.
>
> "Type the value you would have given to --in-reply-to command line
> option (if you forgot to use it), or leave this field empty"
> perhaps? Those who do not know should be able to learn what
> "--in-reply-to" is. A prompt help is not the place to do a
> documentation.

This would be better, yeah, but at that point it's pretty weird, like
why are we prompting for this CLI flag and not any others? The answer is
just for legacy reasons. There's no inherent justification for it.

> > I hate to be a nuisance over such a seemingly simple problem, but there
> > are a lot of new users who are struggling here and I care about their
> > struggle. What path should we take to fixing this issue for them?
>
> The ideal way would be to craft step (0) well enough so that new
> users trigger the To: prompt in the first place, which would
> automatically make the problem disappear ;-)

Do you mean teaching users how to use --to upfront? Honestly the prompt
seems totally fine to me, there's nothing wrong with a use-case which
calls for typing your To address into the prompt. Hell, often I'll use
it, or I'll use --annotate and write my To addresses in vim.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Junio C Hamano]

"Drew DeVault" <sir@cmpwn.com> writes:

> This would be better, yeah, but at that point it's pretty weird, like
> why are we prompting for this CLI flag and not any others? The answer is
> just for legacy reasons. There's no inherent justification for it.

I suspect that the legacy reason exists only because it was (thought
to be) (a) common enough to make a series in response to an existing
message than a thread starter and (b) "to:" and "in-reply-to:" are
quite close to make sense to be asked together [*1*], back when the
current behaviour was established, ?  In other words, the "legacy
reson" may have inherent justification for it.

Your primary and only argument to flip the default not to ask about
in-reply-to is, because, in your opinion, more users would want to
send thread-starters than responses.  I haven't seen the numbers,
and more importantly I do not think anybody can expected to produce
numbers that convince everybody (there are biases based on who's
counting and what is counted), so I cannot buy such an argument
blindly.

The weighing done, perhaps in the original author's mind, back when
send-email was written would certainly not be based on any concrete
numbers, either.  But as one undisputable fact we know [*2*] is that
quite many people are already used to the behaviour we currently
have.  While some of them may welcome change, others will complain
if they are forced to relearn what they have committed to their
muscle memory.  

That makes it the safest thing to give users a new choice without
changing the default.  That would allow us at least move forward.



[Footnote]

*1* After all, these two affect where the readers find the message,
    i.e. in the archive or mailbox of which mailing list, and where
    in relation to other messages in the list.

*2* Purely based on how widely git is used.

Re: [PATCH] send-email: do not prompt for In-Reply-To

[Drew DeVault]

On Fri Aug 28, 2020 at 5:33 PM EDT, Junio C Hamano wrote:
> I suspect that the legacy reason exists only because it was (thought
> to be) (a) common enough to make a series in response to an existing
> message than a thread starter and (b) "to:" and "in-reply-to:" are
> quite close to make sense to be asked together [*1*], back when the
> current behaviour was established, ? In other words, the "legacy
> reson" may have inherent justification for it.

I understand what you mean, but like you said, without a time machine to
peer into the mind of the original author, this is an assumption without
evidence. If we cannot come up with a renewed justification it... does
it really still hold on the basis that it may or may not have been
adequately justified at some point in the distant past?

> Your primary and only argument to flip the default not to ask about
> in-reply-to is, because, in your opinion, more users would want to
> send thread-starters than responses. I haven't seen the numbers,
> and more importantly I do not think anybody can expected to produce
> numbers that convince everybody (there are biases based on who's
> counting and what is counted), so I cannot buy such an argument
> blindly.

I would agree that this is part of my argument, but it's only a
supporting argument, not my primary argument. The primary argument is
that understanding and answering the prompt requires domain-specific
knowledge about email internals which are not normally presented to the
user. I am unaware of any mail client which makes the meaning or even
the existence of the Message-ID or In-Reply-To headers known to the user
without going out of their way to find it. Explaining the meaning of
these fields, how to find them for their mail client, and when to use
them, would be well outside the scope for the prompt itself.

No one has yet come forward to vouch for this branch as something they
actually depend on, by the way. It's just been people who are unaffected
making arguments that such a user may exist in theory. Maybe we could
figure it for sure out by putting a prompt in this branch, like you
initially suggested?

> That makes it the safest thing to give users a new choice without
> changing the default. That would allow us at least move forward.

Well, it'd be a start, and I may very well write that patch for the sake
of moving forward, as you say. But it doesn't solve the problem I came
here to solve, unless viewed as the first of several steps towards its
eventual removal.