{"thread":{"id":"54145","subject":"[PATCH] send-email: do not prompt for In-Reply-To","startedAt":"2020-08-27T17:55:58Z","lastAt":"2020-08-28T21:46:21Z","messageCount":29,"participants":["Drew DeVault","Junio C Hamano","Carlo Marcelo Arenas Belón","Carlo Arenas","Raymond E. Pasco"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"404638","messageId":"20200827175552.132193-1-sir@cmpwn.com","threadId":"54145","inReplyTo":null,"subject":"[PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T17:55:52Z","receivedAt":"2020-08-27T17:55:58Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Most mailing lists prefer that new patchsets and their revisions are\nplaced into a new thread. Additionally, knowledge of what In-Reply-To\nmeans and where to find the Message-Id to fill in are domain-specific\nand confusing to new users. In the niche situations where this is called\nfor, the --in-reply-to flag is sufficient.\n\nA config option, sendemail.promptInReplyTo, has been added to re-enable\nthe old behavior.\n---\n Documentation/config/sendemail.txt | 7 +++++++\n git-send-email.perl                | 5 ++++-\n 2 files changed, 11 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt\nindex cbc5af42fd..34ca8263d0 100644\n--- a/Documentation/config/sendemail.txt\n+++ b/Documentation/config/sendemail.txt\n@@ -66,3 +66,10 @@ sendemail.forbidSendmailVariables::\n \tTo avoid common misconfiguration mistakes, linkgit:git-send-email[1]\n \twill abort with a warning if any configuration options for \"sendmail\"\n \texist. Set this variable to bypass the check.\n+\n+sendemail.promptInReplyTo::\n+\tPrevious versions of linkgit:git-send-email[1] would prompt the user to\n+\tinput an In-Reply-To header for every patchset sent. This was removed as\n+\tthe default behavior, being generally undesirable on most mailing lists,\n+\tand confusing for new users. Set this variable to re-enable the old\n+\tbehavior.\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 1f425c0809..f3abccef6d 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -251,6 +251,7 @@ sub do_edit {\n my $validate = 1;\n my $target_xfer_encoding = 'auto';\n my $forbid_sendmail_variables = 1;\n+my $prompt_in_reply_to = 0;\n \n my %config_bool_settings = (\n     \"thread\" => \\$thread,\n@@ -265,6 +266,7 @@ sub do_edit {\n     \"annotate\" => \\$annotate,\n     \"xmailer\" => \\$use_xmailer,\n     \"forbidsendmailvariables\" => \\$forbid_sendmail_variables,\n+    \"promptinreplyto\" => \\$prompt_in_reply_to,\n );\n \n my %config_settings = (\n@@ -467,6 +469,7 @@ sub read_config {\n \t\t    \"batch-size=i\" => \\$batch_size,\n \t\t    \"relogin-delay=i\" => \\$relogin_delay,\n \t\t    \"git-completion-helper\" => \\$git_completion_helper,\n+\t\t    \"prompt-in-reply-to\" => \\$prompt_in_reply_to,\n \t );\n \n # Munge any \"either config or getopt, not both\" variables\n@@ -978,7 +981,7 @@ sub expand_one_alias {\n @initial_cc = process_address_list(@initial_cc);\n @initial_bcc = process_address_list(@initial_bcc);\n \n-if ($thread && !defined $initial_in_reply_to && $prompting) {\n+if ($thread && !defined $initial_in_reply_to && $prompting && $prompt_in_reply_to) {\n \t$initial_in_reply_to = ask(\n \t\t__(\"Message-ID to be used as In-Reply-To for the first email (if any)? \"),\n \t\tdefault => \"\",\n-- \n2.28.0\n\n"},{"id":"404639","messageId":"xmqq7dtjrjut.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"20200827175552.132193-1-sir@cmpwn.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T19:04:26Z","receivedAt":"2020-08-27T19:04:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Drew DeVault <sir@cmpwn.com> writes:\n\n> Most mailing lists prefer that new patchsets and their revisions are\n> placed into a new thread. Additionally, knowledge of what In-Reply-To\n> means and where to find the Message-Id to fill in are domain-specific\n> and confusing to new users. In the niche situations where this is called\n> for, the --in-reply-to flag is sufficient.\n>\n> A config option, sendemail.promptInReplyTo, has been added to re-enable\n> the old behavior.\n\nWe do not break existing users' habits without a good reason, and a\nsubjective \"this is the way I prefer\" is *not* a good reason.\n\nIf/when the claim \"most mailing lists prefer\" can be substantiated,\nwe'd need to devise a transition plan to flip the default over\nseveral releases.  Here is how I would envision the plan should go.\n\n (0) Introduce sendemail.promptInReplyTo that defaults to true; this\n     can be done today and it would be a genuine improvement for\n     those who want the new behaviour, without hurting any existing\n     users.\n\n (1) Substantiate the \"most mailing list prefer\" claim.  If we\n     cannot, we stop here.  Otherwise we would move to the next\n     step.\n\n (2) Teach \"git send-email\" to issue a warning message when the\n     telling the user that the default will be flipped in some\n     future version of Git and optionally ask them to tell us to\n     stop on the mailing list, when sendemail.promptInReplyTo\n     configuration variable is not set.\n\n     Advertise the future flip of the default in other channels,\n     too.\n\n (3) Wait for at least a few releases.  Monitor the mailing list and\n     other channels for objections, and if it becomes clear that we\n     misjudged in step (1), stop the transition plan by reverting to\n     the state before step (2) (i.e. not to before step (0)).\n\n (4) Flip the default and tweak the message to tell those users who\n     still do not have sendemail.promptInReplyTo variable set that\n     the default have changed, and if they want to get prompted,\n     they must set the variable to true.  Also stop asking them to\n     tell us to stop---at this point we are committed and will not\n     go back.\n\n (5) Waiting for several releases\n\n (6) Remove the code to give messages for users who do not have the\n     configuration variable.\n\n\n"},{"id":"404641","messageId":"xmqq3647rjnt.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"xmqq7dtjrjut.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T19:08:38Z","receivedAt":"2020-08-27T19:08:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Drew DeVault <sir@cmpwn.com> writes:\n>\n>> Most mailing lists prefer that new patchsets and their revisions are\n>> placed into a new thread. Additionally, knowledge of what In-Reply-To\n>> means and where to find the Message-Id to fill in are domain-specific\n>> and confusing to new users. In the niche situations where this is called\n>> for, the --in-reply-to flag is sufficient.\n>>\n>> A config option, sendemail.promptInReplyTo, has been added to re-enable\n>> the old behavior.\n>\n> We do not break existing users' habits without a good reason, and a\n> subjective \"this is the way I prefer\" is *not* a good reason.\n\nHaving said that (and I am not retracting anything I said in the\nmessage I am responding to), I haven't seen this prompt triggering\nfor me when I use send-email, with or without --in-reply-to option\non the command line.\n\nAdmittedly I use a wrapper around \"git send-email\" to add minimum\nset of command line options that are always used (they are --from,\n--envelope-sender, and --smtp-server) but I do not think they have\neffect on the use of in-reply-to prompt.  \n\nWhat are we doing differently, I wonder?\n\n\n"},{"id":"404642","messageId":"C580P9BS4VYA.15I6SHXQQ35HF@homura","threadId":"54145","inReplyTo":"xmqq3647rjnt.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T19:14:57Z","receivedAt":"2020-08-27T19:15:07Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Do you have sendemail.to set in your local git config?\n"},{"id":"404643","messageId":"C580PCBW40LU.3EIZ34DNZN9B5@homura","threadId":"54145","inReplyTo":"xmqq7dtjrjut.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T19:15:03Z","receivedAt":"2020-08-27T19:15:21Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Okay, thanks for the info! I'll take this back to the drawing board and\ncome up with a plan which follows more closely to that.\n"},{"id":"404644","messageId":"xmqqy2lzq4h4.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"C580P9BS4VYA.15I6SHXQQ35HF@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T19:21:59Z","receivedAt":"2020-08-27T19:22:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> Do you have sendemail.to set in your local git config?\n\nYes, and I'd assume most mailing list have a single to: address, and\npeople use a repository to interact with just a single project, so I\nthink it would be natural to have it in the per-repository\nconfiguration file.  Is it true that you do not set it and that the\nlack of the configuration is why you are getting prompted?\n\nI suspect that it may not make much sense for the presense of\nsendemail.to to affect prompting for other header fields (iow, my\nnot getting prompted might be a bug).\n\nThanks.\n\n"},{"id":"404645","messageId":"20200827192029.GA63138@Carlos-MBP","threadId":"54145","inReplyTo":"C580P9BS4VYA.15I6SHXQQ35HF@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2020-08-27T19:20:29Z","receivedAt":"2020-08-27T19:22:07Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:\n> Do you have sendemail.to set in your local git config?\n\nI do and can't reproduce either; which version of git do you have this\nproblem with?\n\nCarlo\n"},{"id":"404646","messageId":"C580V29CV3CD.206BQIAA5KQKM@homura","threadId":"54145","inReplyTo":"xmqqy2lzq4h4.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T19:22:32Z","receivedAt":"2020-08-27T19:22:49Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Thu Aug 27, 2020 at 3:21 PM EDT, Junio C Hamano wrote:\n> Yes, and I'd assume most mailing list have a single to: address, and\n> people use a repository to interact with just a single project, so I\n> think it would be natural to have it in the per-repository\n> configuration file. Is it true that you do not set it and that the\n> lack of the configuration is why you are getting prompted?\n\nNo, this didn't make sense, I was mistaken. This shouldn't be the cause.\n"},{"id":"404647","messageId":"C580VF2ZNJ0D.2WFFMIG1B5LO3@homura","threadId":"54145","inReplyTo":"20200827192029.GA63138@Carlos-MBP","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T19:23:00Z","receivedAt":"2020-08-27T19:23:22Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"I can reproduce both on git 2.28.0 and on github.com/git/git master.\n"},{"id":"404649","messageId":"xmqqtuwnq3x1.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"20200827192029.GA63138@Carlos-MBP","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T19:34:02Z","receivedAt":"2020-08-27T19:34:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n\n> On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:\n>> Do you have sendemail.to set in your local git config?\n>\n> I do and can't reproduce either; which version of git do you have this\n> problem with?\n\nAny recent version of git-send-email, I would say.  The relevant\ncode snippets are:\n\n    my $prompting = 0;\n    if (!@initial_to && !defined $to_cmd) {\n            my $to = ask(\"$to_whom \",\n                         default => \"\",\n                         valid_re => qr/\\@.*\\./, confirm_only => 1);\n            push @initial_to, parse_address_line($to) if defined $to; #\n            $prompting++;\n    }\n    ...\n    @initial_to = process_address_list(@initial_to);\n    @initial_cc = process_address_list(@initial_cc);\n    @initial_bcc = process_address_list(@initial_bcc);\n\n    if ($thread && !defined $initial_in_reply_to && $prompting) {\n            $initial_in_reply_to = ask(\n                    __(\"Message-ID to be used as In-Reply-To for the first email (if any)? \"),\n                    default => \"\",\n                    valid_re => qr/\\@.*\\./, confirm_only => 1);\n    }\n\nwhere initial_to is set either from the command line or sendemail.to\nconfiguration variable and before the control reaches this section\nof the code.  In addition to realizing \"ah, To: address is not given\nso we need to ask\" and ask the to address, it says \"since we have\nalready interatively asked the end-user anyway, we can and should\nask other things as well\" by incrementing $prompting.\n\nThat feels both understandable and bogus at the same time.  To:\nis pretty much required (yes, you can use cc: and bcc: without any\naddress on To:, but that is not something you'd usually do to send\npatches to mailing lists), so lack of it means either asking\ninteractively or aborting.  But other things like in-reply-to are\noptional, and tying the decision to prompt for them or not does not\nfeel OK.\n\n"},{"id":"404650","messageId":"20200827193234.GB63138@Carlos-MBP","threadId":"54145","inReplyTo":"C580VF2ZNJ0D.2WFFMIG1B5LO3@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2020-08-27T19:32:34Z","receivedAt":"2020-08-27T19:34:10Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Aug 27, 2020 at 03:23:00PM -0400, Drew DeVault wrote:\n> I can reproduce both on git 2.28.0 and on github.com/git/git master.\n\nand you use --compose to send an email thread directly instead of\ndoing first `git-format-patch -o`?\n\nCarlo\n"},{"id":"404651","messageId":"C5814BWVXMP3.1GJ83FMKYSFTY@homura","threadId":"54145","inReplyTo":"xmqqtuwnq3x1.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T19:34:38Z","receivedAt":"2020-08-27T19:35:19Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Do you think this whole workstream could be averted by dropping the\n$prompting check in the in-reply-to branch?\n\nOr would that still constitute a breaking change to user workflows?\n"},{"id":"404652","messageId":"CAPUEspjmnjX5Lwd1cSdDzJRdRUGT8Gk6At7BchRsX=fsuAZE9Q@mail.gmail.com","threadId":"54145","inReplyTo":"C5814BWVXMP3.1GJ83FMKYSFTY@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2020-08-27T19:46:15Z","receivedAt":"2020-08-27T19:46:30Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Aug 27, 2020 at 12:35 PM Drew DeVault <sir@cmpwn.com> wrote:\n> Do you think this whole workstream could be averted by dropping the\n> $prompting check in the in-reply-to branch?\n>\n> Or would that still constitute a breaking change to user workflows?\n\nI think the \"breaking change\" is changing the default (which needs\nfixing as well).\n\nbut an interesting idea would be to add a config so the prompting\ncould be skipped which would be something that people could add to\ntheir per repository config (as needed).\n\nCarlo\n"},{"id":"404658","messageId":"20200827220249.GA71190@Carlos-MBP","threadId":"54145","inReplyTo":"xmqqtuwnq3x1.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2020-08-27T22:02:49Z","receivedAt":"2020-08-27T22:02:54Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:\n> \n> That feels both understandable and bogus at the same time.  To:\n> is pretty much required (yes, you can use cc: and bcc: without any\n> address on To:, but that is not something you'd usually do to send\n> patches to mailing lists), so lack of it means either asking\n> interactively or aborting.  But other things like in-reply-to are\n> optional, and tying the decision to prompt for them or not does not\n> feel OK.\n\nbut trying to \"fix\" this breaks 10 year old tests, so it is obvious\nthat everyone already expects it to work this way (probably hidden\nby the fact most people don't let git-send-email prompt for \"To:\")\n\nthe patch after the scissors attempts to document the current \"Legacy\"\nbehaviour which should be worth doing regardless of what is done with\nthis patch.\n\nbut I suspect it might be worth adding a new configuration flag like\nthe one that was propossed so that the prompting could be set per\nrepository to either \"Always\" (for when forgetting it will break the\nthreads in lists that care, like this one) and \"Never\" (for when the\nlists explicitally ask mails to be send without one, because they\nuse patchew or equivalent (ex: qemu-devel[1])).\n\nCarlo\n\n[1] https://wiki.qemu.org/Contribute/SubmitAPatch\n--- >8 ---\nSubject: [PATCH] send-email: document logic for In-Reply-To prompting\n\nEventhough there doesn't seem to be a good reason for it, it is\nthe way it has been implemented for the last 10 years.\n\nDocument the current behaviour (which the tests also depend on)\nbefore it can be tweaked by a future per repository setting.\n\nSigned-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n---\n Documentation/git-send-email.txt | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 0a69810147..8e9ebb3fac 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -108,8 +108,7 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:\n       [PATCH v2 2/3] New tests\n       [PATCH v2 3/3] Implementation\n +\n-Only necessary if --compose is also set.  If --compose\n-is not set, this will be prompted for.\n+If --compose is not set, and there is no known \"To:\" this will be prompted for.\n \n --subject=<string>::\n \tSpecify the initial subject of the email thread.\n-- \n2.28.0.424.gade71fd49b\n\n"},{"id":"404660","messageId":"xmqqd03bpuh7.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"20200827220249.GA71190@Carlos-MBP","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T22:57:56Z","receivedAt":"2020-08-27T22:58:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:\n\n> On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:\n>> \n>> That feels both understandable and bogus at the same time.  To:\n>> is pretty much required (yes, you can use cc: and bcc: without any\n>> address on To:, but that is not something you'd usually do to send\n>> patches to mailing lists), so lack of it means either asking\n>> interactively or aborting.  But other things like in-reply-to are\n>> optional, and tying the decision to prompt for them or not does not\n>> feel OK.\n>\n> but trying to \"fix\" this breaks 10 year old tests, so it is obvious\n> that everyone already expects it to work this way (probably hidden\n> by the fact most people don't let git-send-email prompt for \"To:\")\n\nOh, I agree with that 100%.\n\n> -Only necessary if --compose is also set.  If --compose\n> -is not set, this will be prompted for.\n> +If --compose is not set, and there is no known \"To:\" this will be prompted for.\n\nThe updated sentence structure, with or without the mention of\n\"to:\", reads much better than the original.  \n\nThe original told them that they must give it from the command line\nin \"--compose\" mode, because they will not be given the chance to\ngive it interactively, and the intended target audience was those\nwho want to send a message with in-reply-to (which is natural, as\nthis is a description for that option).\n\nThe updated message says the same thing, but is audience-neutral and\ntries to be more useful to folks who are not responding to any\nmessage.  I.e. outside \"--compose\" mode, you'll be asked if you want\nto make it a response, unless you gave \"to:\".\n\nBy losing the \"we won't ask so you must give it from the command\nline\" message in the original, the resulting description has become\neasier to follow, I think.  Those who do want to add the header,\nwhen they reach this description in the manual, already knows that\nthere is a command line option.\n\nTo help those who do not want to add this header, it would probably\nbe more helpful to tell what to do when prompted (like \"you can give\nan empty answer to tell the command that you are not responding to\nany message\").\n\nThanks.\n\n"},{"id":"404662","messageId":"C585GT9K2V93.4O470Q21FXFD@homura","threadId":"54145","inReplyTo":"xmqqd03bpuh7.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T22:59:01Z","receivedAt":"2020-08-27T23:04:23Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:\n> To help those who do not want to add this header, it would probably\n> be more helpful to tell what to do when prompted (like \"you can give\n> an empty answer to tell the command that you are not responding to\n> any message\").\n\nI don't like this solution. We should make it harder to do the wrong\nthing, and easier to do the right thing.\n\nIt would be helpful for git to take an opinionated stance on the right\nway to send emails with it, since no one else is really in the position\nto. This behavior has confused many people that I've spoken with and\nmakes for a rough introduction to a tool which people are already loathe\nto learn. git send-email is really the best way to send emails with git,\nand will save the user a lot of trouble in the future if they figure it\nout, so I want it to be as easy to figure out as possible.\n\nEven so, I understand the concerns raised so far. I haven't started on\nv2 yet, but my rough plan is to add a config option along the lines of\nsendemail.verbosePrompts, defaulted to on for now, which enables the\npresent-day behavior, along with a message stating the intention to\nchange the behavior in a future release, and an invitation to comment on\nthe mailing list.\n\nThe behavior of this flag if set to false would be equivalent to\nremoving the $prompting condition in the if statement which controls\nwhether or not this prompt is shown.\n"},{"id":"404663","messageId":"C585M18ZSR87.2CMIKK2VKMC1S@homura","threadId":"54145","inReplyTo":"C585GT9K2V93.4O470Q21FXFD@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T23:05:50Z","receivedAt":"2020-08-27T23:07:06Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"Oh, and I should mention the fact that this breaking change is less\nsevere than we initially thought, only breaking an edge case - when --to\nis not specified - so it's likely to have a pretty small impact. We'll\nfind out when someone emails us to complain, I suppose.\n"},{"id":"404664","messageId":"xmqq4konptab.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"C585GT9K2V93.4O470Q21FXFD@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T23:23:40Z","receivedAt":"2020-08-27T23:23:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:\n>> To help those who do not want to add this header, it would probably\n>> be more helpful to tell what to do when prompted (like \"you can give\n>> an empty answer to tell the command that you are not responding to\n>> any message\").\n>\n> I don't like this solution. We should make it harder to do the wrong\n> thing, and easier to do the right thing.\n\nCarlo and I were discussing how best to describe the behaviour we\nhave better to the users, which is unrelated to any code change that\nwould be required to \"make it harder make it easier.\"  \n\nWe need to do so to help users in the meantime, before any behaviour\nchange (which need to happen over several releases, as outlined\nearlier) happens.\n\n\n\n\n"},{"id":"404665","messageId":"C58604CW0C8Y.27SRQLJ1C6X43@homura","threadId":"54145","inReplyTo":"xmqq4konptab.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-27T23:24:14Z","receivedAt":"2020-08-27T23:24:50Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Thu Aug 27, 2020 at 7:23 PM EDT, Junio C Hamano wrote:\n> Carlo and I were discussing how best to describe the behaviour we\n> have better to the users, which is unrelated to any code change that\n> would be required to \"make it harder make it easier.\"\n>\n> We need to do so to help users in the meantime, before any behaviour\n> change (which need to happen over several releases, as outlined\n> earlier) happens.\n\nAh, I see what you mean. I'll add some messaging like that in my v2, but\nthe point's likely moot anyway since I expect to have the patch ready\nfor the next release.\n"},{"id":"404669","messageId":"xmqqsgc7oa5s.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"C585M18ZSR87.2CMIKK2VKMC1S@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-28T01:02:07Z","receivedAt":"2020-08-28T01:02:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> Oh, and I should mention the fact that this breaking change is less\n> severe than we initially thought, only breaking an edge case - when --to\n> is not specified - so it's likely to have a pretty small impact. We'll\n> find out when someone emails us to complain, I suppose.\n\nI agree that it is likely that only very small population even gets\nbittn by this \"in-reply-to gets prompted\" issue, because it is\nunlikely for users not to give \"to:\" address in one way or another\nand let the prompt logic to ask them.\n\nWhich means that it is OK to stop at step (0) in the long transition\nsequence I outlined in a previous message from me.  \n\nThat is, introduce a configuration variable that can be set to 'no'\nby those who do not want to be prompted for \"in-reply-to:\" when they\ndid not give \"to:\" and let the prompt logic to ask \"to:\", document\nthe variable well [*1*], and make sure the default behaviour when\nthe variable is not set is the same as now.\n\nThat way, we do not even need to debate if it is true that most\nusers do not want in-reply-to (i.e. step (1)).  That's the kind of\nthing that is very hard to establish.\n\nThe minority who wants to use an updated behaviour can just set the\nconfiguration once and the problem is behind them.  The minority who\nwants to keep the current behaviour do not have to do anything.  And\nthere is no impact to the majority of people either way.\n\nI hate having to go through a multi cycle compatibility-breaking\ntransition, because it would consume unnecessary resources from this\nlist (i.e. developer attention is the most scarce common resource\nthat must be shared across topics here), and we would avoid that\ncost altogether because the affected population seems to be small\nenough that it is not worth going through the rigmarole of flipping\nthe default.  That alone is a big plus.\n\nIt seems like we managed to cut down the scope quite a bit.  \n\nThanks.\n\n\n[Footnote]\n\n*1* As a part of \"document the variable well\", we can include a\nmessage tweak for the prompt that asks for \"in-reply-to:\" to say\nsomething like \"if you never want to be prompted for in-reply-to:,\nyou can set this variable\" when the variable is not set at all.\nThose who did set the variable but still are getting the prompt are\nexplicitly opting into keeping the current behaviour by setting it\nto 'yes', so they do not have to see that extra part of the message.\n"},{"id":"404670","messageId":"C5889MKRLCLQ.38RAZT2KCK6Q9@homura","threadId":"54145","inReplyTo":"xmqqsgc7oa5s.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-28T01:10:41Z","receivedAt":"2020-08-28T01:12:19Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Thu Aug 27, 2020 at 9:02 PM EDT, Junio C Hamano wrote:\n> The minority who wants to use an updated behaviour can just set the\n> configuration once and the problem is behind them. The minority who\n> wants to keep the current behaviour do not have to do anything. And\n> there is no impact to the majority of people either way.\n\nEh, this would defeat the purpose. I hate the multi-cycle\ncompatibility-breaking dance as much as the next guy, but the whole\nreason I'm here is to solve a real problem which noobs are encountering.\nI on-board a lot of people with git-send-email and I've heard questions\nand confusions over this prompt at least 10 times in the past few years.\nCompatibility breakage is annoying but this is a real problem which real\nusers are having real difficulty with, and the demographic of affected\nuser may be particularly ill-equipped to deal with it on their own.\n"},{"id":"404671","messageId":"C588ZA2QAFBS.23DYVMBK3E0X6@ziyou.local","threadId":"54145","inReplyTo":"xmqqsgc7oa5s.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-08-28T01:44:11Z","receivedAt":"2020-08-28T01:53:59Z","isPatch":true,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"On Thu Aug 27, 2020 at 9:02 PM EDT, Junio C Hamano wrote:\n> I agree that it is likely that only very small population even gets\n> bittn by this \"in-reply-to gets prompted\" issue, because it is\n> unlikely for users not to give \"to:\" address in one way or another\n> and let the prompt logic to ask them.\n\nThe merits of this thread's proposal aside, send-email's prompting has\nalways seemed half-baked to me - it often doesn't even show up, and\ndoesn't prompt for some things that would be useful like additional CCs\n(and if you're setting In-Reply-To, there are probably additional CCs).\n\nThe prompts have helped me not flub emails before, but arguably that's\nnot good since they're often not even shown and someone may come to rely\non their presence only to later accidentally turn them off.\n\nAnyway, it's worth noting that, because the prompts *do* exist,\nhalf-baked as they are, it's not really safe to assume that nobody sees\nthem. There might be a sizable population out there never specifying\n\"--to\" because they know they'll be prompted for it.\n"},{"id":"404672","messageId":"C5898IRIGV23.CBS4D6546Y9K@homura","threadId":"54145","inReplyTo":"C588ZA2QAFBS.23DYVMBK3E0X6@ziyou.local","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-28T01:56:15Z","receivedAt":"2020-08-28T01:57:11Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Thu Aug 27, 2020 at 9:44 PM EDT, Raymond E. Pasco wrote:\n> Anyway, it's worth noting that, because the prompts *do* exist,\n> half-baked as they are, it's not really safe to assume that nobody sees\n> them. There might be a sizable population out there never specifying\n> \"--to\" because they know they'll be prompted for it.\n\nI hardly ever use --to for one-off patches or repositories which I'm not\nregularly contributing to, and I expect that prompt. In-Reply-To has a\nmuch less compelling argument, though, as Junio pointed out, given that\nit's often not necessary or desirable, whereas for \"to\", every email has\nto have at least one recipient to make sense.\n"},{"id":"404717","messageId":"C58UKAYKF1ZY.V5LLW3DY1KAY@homura","threadId":"54145","inReplyTo":"xmqqd03bpuh7.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-28T18:39:02Z","receivedAt":"2020-08-28T18:49:55Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:\n> To help those who do not want to add this header, it would probably\n> be more helpful to tell what to do when prompted (like \"you can give\n> an empty answer to tell the command that you are not responding to\n> any message\").\n\nI'm trying to come up with a message like this for a reduced-scope\ninitial patch, but I'm drawing up a blank when the goal is to avoid\nconfusing users who don't understand this. The goal is to remove\ndomain-specific knowledge about email, namely how the In-Reply-To and\nMessage-Id headers work, which is uncommon knowledge among new users.\n\n\"You can give an empty answer if you are not responding to any message\"\ncould confuse users, because they might think -v2 is a \"response\", or\nmaybe they've written the patch in response to a discussion on the\n-users mailing list, or any other number of reasons. Now they have to\nfigure out how to answer this prompt, even if the mailing list they're\nsending it to isn't expecting it to be a reply. I came up with a number\nof alternative wordings but they all ultimately failed to this same\nproblem.\n\nIn-Reply-To is such an arcane and tangental piece of knowledge so far\nremoved from git, and so little information is given to the user to help\nthem understand (1) what it is, and (2) whether they need it or not, and\n(3) where to find it, that this prompt just seems totally awful to me.\nIt'd be like if we prompted someone to enter their display EDID when\nfiling a bug for a video game. Could it be useful? It's unlikely. Is the\nuser likely to know what the hell an EDID is? Almost certainly not!\n\n\"Legitimate\" use-cases like qemu-devel or not, this is only ever going\nto confuse new users, and I think that qemu is wrong for encouraging\nusers to deal with it.\n\nOr they would be wrong, but I looked into it and, the qemu wiki advises\nthat the user does *not* use in-reply-to:\n\nhttps://wiki.qemu.org/Contribute/SubmitAPatch\n\nNor does patchew make it easy to extract the message ID from their\ninterface for this use-case. I'm not sure where this qemu idea is coming\nfrom.\n\nIs compatibility-breaking migrations a nightmare? Well, maybe.\n\nIs that nightmare worth such a trivial problem? Well, it seems trivial\nto those of us who have been using it for years, but I can assure you\nthere are plenty of new users who shut down at this step.\n\nI hate to be a nuisance over such a seemingly simple problem, but there\nare a lot of new users who are struggling here and I care about their\nstruggle. What path should we take to fixing this issue for them?\n"},{"id":"404728","messageId":"xmqqk0xio59r.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"C58UKAYKF1ZY.V5LLW3DY1KAY@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-28T21:00:00Z","receivedAt":"2020-08-28T21:00:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> \"You can give an empty answer if you are not responding to any message\"\n> could confuse users, because they might think -v2 is a \"response\", or\n> maybe they've written the patch in response to a discussion on the\n> -users mailing list, or any other number of reasons.\n\n\"Type the value you would have given to --in-reply-to command line\noption (if you forgot to use it), or leave this field empty\"\nperhaps?  Those who do not know should be able to learn what\n\"--in-reply-to\" is.  A prompt help is not the place to do a\ndocumentation.\n\n> I hate to be a nuisance over such a seemingly simple problem, but there\n> are a lot of new users who are struggling here and I care about their\n> struggle. What path should we take to fixing this issue for them?\n\nThe ideal way would be to craft step (0) well enough so that new\nusers trigger the To: prompt in the first place, which would\nautomatically make the problem disappear ;-)\n\n"},{"id":"404730","messageId":"C58XLLAE3SMA.3T1C6DXZ4VSWA@homura","threadId":"54145","inReplyTo":"xmqqk0xio59r.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-28T21:01:46Z","receivedAt":"2020-08-28T21:03:08Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Fri Aug 28, 2020 at 5:00 PM EDT, Junio C Hamano wrote:\n> \"Drew DeVault\" <sir@cmpwn.com> writes:\n>\n> > \"You can give an empty answer if you are not responding to any message\"\n> > could confuse users, because they might think -v2 is a \"response\", or\n> > maybe they've written the patch in response to a discussion on the\n> > -users mailing list, or any other number of reasons.\n>\n> \"Type the value you would have given to --in-reply-to command line\n> option (if you forgot to use it), or leave this field empty\"\n> perhaps? Those who do not know should be able to learn what\n> \"--in-reply-to\" is. A prompt help is not the place to do a\n> documentation.\n\nThis would be better, yeah, but at that point it's pretty weird, like\nwhy are we prompting for this CLI flag and not any others? The answer is\njust for legacy reasons. There's no inherent justification for it.\n\n> > I hate to be a nuisance over such a seemingly simple problem, but there\n> > are a lot of new users who are struggling here and I care about their\n> > struggle. What path should we take to fixing this issue for them?\n>\n> The ideal way would be to craft step (0) well enough so that new\n> users trigger the To: prompt in the first place, which would\n> automatically make the problem disappear ;-)\n\nDo you mean teaching users how to use --to upfront? Honestly the prompt\nseems totally fine to me, there's nothing wrong with a use-case which\ncalls for typing your To address into the prompt. Hell, often I'll use\nit, or I'll use --annotate and write my To addresses in vim.\n"},{"id":"404733","messageId":"xmqq7dtio3pa.fsf@gitster.c.googlers.com","threadId":"54145","inReplyTo":"C58XLLAE3SMA.3T1C6DXZ4VSWA@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-28T21:33:53Z","receivedAt":"2020-08-28T21:33:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Drew DeVault\" <sir@cmpwn.com> writes:\n\n> This would be better, yeah, but at that point it's pretty weird, like\n> why are we prompting for this CLI flag and not any others? The answer is\n> just for legacy reasons. There's no inherent justification for it.\n\nI suspect that the legacy reason exists only because it was (thought\nto be) (a) common enough to make a series in response to an existing\nmessage than a thread starter and (b) \"to:\" and \"in-reply-to:\" are\nquite close to make sense to be asked together [*1*], back when the\ncurrent behaviour was established, ?  In other words, the \"legacy\nreson\" may have inherent justification for it.\n\nYour primary and only argument to flip the default not to ask about\nin-reply-to is, because, in your opinion, more users would want to\nsend thread-starters than responses.  I haven't seen the numbers,\nand more importantly I do not think anybody can expected to produce\nnumbers that convince everybody (there are biases based on who's\ncounting and what is counted), so I cannot buy such an argument\nblindly.\n\nThe weighing done, perhaps in the original author's mind, back when\nsend-email was written would certainly not be based on any concrete\nnumbers, either.  But as one undisputable fact we know [*2*] is that\nquite many people are already used to the behaviour we currently\nhave.  While some of them may welcome change, others will complain\nif they are forced to relearn what they have committed to their\nmuscle memory.  \n\nThat makes it the safest thing to give users a new choice without\nchanging the default.  That would allow us at least move forward.\n\n\n\n[Footnote]\n\n*1* After all, these two affect where the readers find the message,\n    i.e. in the archive or mailbox of which mailing list, and where\n    in relation to other messages in the list.\n\n*2* Purely based on how widely git is used.\n"},{"id":"404734","messageId":"C58YB5DAHSZF.F67NZSQYAPF7@homura","threadId":"54145","inReplyTo":"xmqq7dtio3pa.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Drew DeVault","fromEmail":"sir@cmpwn.com","sentAt":"2020-08-28T21:35:09Z","receivedAt":"2020-08-28T21:43:30Z","isPatch":true,"sender":{"key":"sir@cmpwn.com","avatar":"https://avatars.githubusercontent.com/u/1310872?v=4"},"body":"On Fri Aug 28, 2020 at 5:33 PM EDT, Junio C Hamano wrote:\n> I suspect that the legacy reason exists only because it was (thought\n> to be) (a) common enough to make a series in response to an existing\n> message than a thread starter and (b) \"to:\" and \"in-reply-to:\" are\n> quite close to make sense to be asked together [*1*], back when the\n> current behaviour was established, ? In other words, the \"legacy\n> reson\" may have inherent justification for it.\n\nI understand what you mean, but like you said, without a time machine to\npeer into the mind of the original author, this is an assumption without\nevidence. If we cannot come up with a renewed justification it... does\nit really still hold on the basis that it may or may not have been\nadequately justified at some point in the distant past?\n\n> Your primary and only argument to flip the default not to ask about\n> in-reply-to is, because, in your opinion, more users would want to\n> send thread-starters than responses. I haven't seen the numbers,\n> and more importantly I do not think anybody can expected to produce\n> numbers that convince everybody (there are biases based on who's\n> counting and what is counted), so I cannot buy such an argument\n> blindly.\n\nI would agree that this is part of my argument, but it's only a\nsupporting argument, not my primary argument. The primary argument is\nthat understanding and answering the prompt requires domain-specific\nknowledge about email internals which are not normally presented to the\nuser. I am unaware of any mail client which makes the meaning or even\nthe existence of the Message-ID or In-Reply-To headers known to the user\nwithout going out of their way to find it. Explaining the meaning of\nthese fields, how to find them for their mail client, and when to use\nthem, would be well outside the scope for the prompt itself.\n\nNo one has yet come forward to vouch for this branch as something they\nactually depend on, by the way. It's just been people who are unaffected\nmaking arguments that such a user may exist in theory. Maybe we could\nfigure it for sure out by putting a prompt in this branch, like you\ninitially suggested?\n\n> That makes it the safest thing to give users a new choice without\n> changing the default. That would allow us at least move forward.\n\nWell, it'd be a start, and I may very well write that patch for the sake\nof moving forward, as you say. But it doesn't solve the problem I came\nhere to solve, unless viewed as the first of several steps towards its\neventual removal.\n"},{"id":"404735","messageId":"C58XJ602TKUG.33AM95HQC9OZ4@ziyou.local","threadId":"54145","inReplyTo":"C58UKAYKF1ZY.V5LLW3DY1KAY@homura","subject":"Re: [PATCH] send-email: do not prompt for In-Reply-To","fromName":"Raymond E. Pasco","fromEmail":"ray@ameretat.dev","sentAt":"2020-08-28T20:58:36Z","receivedAt":"2020-08-28T21:46:21Z","isPatch":true,"sender":{"key":"ray@ameretat.dev","avatar":"https://avatars.githubusercontent.com/u/115765?v=4"},"body":"On Fri Aug 28, 2020 at 2:39 PM EDT, Drew DeVault wrote:\n> \"You can give an empty answer if you are not responding to any message\"\n> could confuse users, because they might think -v2 is a \"response\", or\n> maybe they've written the patch in response to a discussion on the\n> -users mailing list, or any other number of reasons. Now they have to\n> figure out how to answer this prompt, even if the mailing list they're\n> sending it to isn't expecting it to be a reply. I came up with a number\n> of alternative wordings but they all ultimately failed to this same\n> problem.\n\nThese *are* all reasons why a patch would be sent as a reply. You can\nmoderate your own lists however you like, but that does not mean that\npatches being replies to other mails is 1) wrong or useless, or 2) not\nin wide use. I wish the user experience were a bit smoother for those of\nus who aren't dedicated Emacs manglers, but things like scissors lines\nhelp a bit.\n\n> \"Legitimate\" use-cases like qemu-devel or not, this is only ever going\n> to confuse new users, and I think that qemu is wrong for encouraging\n> users to deal with it.\n\nqemu-devel was given by Carlo as an example of a list which does *not*\nkeep discussion together in threads; the example give of a list which\n*does* keep things together in threads was the Git list itself (surely\nthe normative list for Git, if there is such a thing). It's too useful\nto hackers (and presumably maintainers), I don't think anyone is going\nto stop.\n\nLooking at this in isolation from the polemics about list practices,\nit's pretty clear that the way send-email prompts for things is not\nlogical. Axing the In-Reply-To prompt would be one way to make it\nlogical, because the only other prompt is the To prompt; this is removal\nof a prompt users may expect, but by being so inconsistent, the software\nitself already removes the prompt when I'm expecting it!\n\nThere may be other ways to make it logical, like having the appearance\nof the In-Reply-To prompt depend solely on whether a message ID was\nalready provided or not (but since a message ID is not mandatory, it's\nweird to prompt for it and not for, say, additional CCs).\n\nSince every mail client I've ever seen has a \"reply\" button, I don't\nthink the concept of a reply is eldritch arcana that users must be\nprotected from. It's annoying to have to get a Message-ID and paste it,\nsure. It would be nice if a mail client could do that for me (I think\ndedicated Emacs manglers are insulated from this problem for that\nreason). Probably whoever prompted for it in the first place just didn't\nwant to flub a message by leaving it out, which wouldn't be an issue for\na client command invoked as some variation on \"reply all\".\n"}]}