{"thread":{"id":"57775","subject":"Should sendemail.confirm default to always?","startedAt":"2022-04-21T19:48:41Z","lastAt":"2022-04-22T17:09:25Z","messageCount":15,"participants":["Alyssa Ross","Ævar Arnfjörð Bjarmason","Junio C Hamano","rsbecker@nexbridge.com","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"454156","messageId":"20220421194832.lshqkl3bogy2f2hy@eve","threadId":"57775","inReplyTo":null,"subject":"Should sendemail.confirm default to always?","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2022-04-21T19:48:32Z","receivedAt":"2022-04-21T19:48:41Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"I was recently having a conversation with some people used to the\nGitHub-style Pull Request workflow, who told me that they feel scared of\nusing git send-email in case they make a mistake and e.g. get the\nrecipients wrong, since they can't correct it after sending.  They can\nresend, but if they do that they'll feel like they're bothering some\nvery busy people by having sent them the same message twice (regardless\nof whether those people are actually bothered by it, it's scary).\n\nThis made me remember feeling that same sense of fear when I used\ngit send-email the first few times.  At some point I discovered that I\ncould set sendemail.confirm to always, and then git would always prompt\nme before sending a message, and I could review the recipients list,\nedit the message if I wanted to, etc.  After that, I was happy, and\ncompletely forgot that that wasn't the default behaviour until having\nthis conversation.\n\nSo I thought it was worth asking, might it be a good idea to change the\ndefault, and have git always prompt before sending mail unless it's told\notherwise?  Expert users will be able to figure out how to change this\ndefault if they don't like it, but novice users won't have bad first\nexperiences where they accidentally send out an email before they were\nready any more.\n\nI don't think this change would cause too much hassle for people\nexpecting the current default, because the current default is for git to\nprompt *sometimes*.  So anybody who doesn't like being prompted is\nlikely to have already disabled it.\n\nThese git users (who are probably in the majority!) are used to having\nedit and delete buttons, so for them the idea of having to get things\nright the first time is scary enough with a preview, let alone without\none.  I hope you can empathize.\n\nThanks!\n\nAlyssa Ross\n"},{"id":"454164","messageId":"220421.86tuam5hoi.gmgdl@evledraar.gmail.com","threadId":"57775","inReplyTo":"20220421194832.lshqkl3bogy2f2hy@eve","subject":"Re: Should sendemail.confirm default to always?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-21T19:58:06Z","receivedAt":"2022-04-21T20:02:12Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Apr 21 2022, Alyssa Ross wrote:\n\n> [[PGP Signed Part:Undecided]]\n> I was recently having a conversation with some people used to the\n> GitHub-style Pull Request workflow, who told me that they feel scared of\n> using git send-email in case they make a mistake and e.g. get the\n> recipients wrong, since they can't correct it after sending.  They can\n> resend, but if they do that they'll feel like they're bothering some\n> very busy people by having sent them the same message twice (regardless\n> of whether those people are actually bothered by it, it's scary).\n>\n> This made me remember feeling that same sense of fear when I used\n> git send-email the first few times.  At some point I discovered that I\n> could set sendemail.confirm to always, and then git would always prompt\n> me before sending a message, and I could review the recipients list,\n> edit the message if I wanted to, etc.  After that, I was happy, and\n> completely forgot that that wasn't the default behaviour until having\n> this conversation.\n>\n> So I thought it was worth asking, might it be a good idea to change the\n> default, and have git always prompt before sending mail unless it's told\n> otherwise?  Expert users will be able to figure out how to change this\n> default if they don't like it, but novice users won't have bad first\n> experiences where they accidentally send out an email before they were\n> ready any more.\n>\n> I don't think this change would cause too much hassle for people\n> expecting the current default, because the current default is for git to\n> prompt *sometimes*.  So anybody who doesn't like being prompted is\n> likely to have already disabled it.\n>\n> These git users (who are probably in the majority!) are used to having\n> edit and delete buttons, so for them the idea of having to get things\n> right the first time is scary enough with a preview, let alone without\n> one.  I hope you can empathize.\n\nAs a regular user of it, I have it set to sendemail.confirm=always. I\ncan see that (goes and looks) a bit over 10% of it git blame's to me,\nand I'd find it too scary to operate without that mode :)\n\nNow, I'd honestly forgotten that wasn't the default mode (I set it many\nyears ago), but I for one think that setting makes sense.\n\nI think a patch to do that would be worth having/reviewing (hint\nhint!). As always the real work is updating docs, running the tests\netc., digging up ML discussions to see if there's been any past\narguments for/against it etc.\n\nIn this case the code change itself should be trivial (I honestly didn't\nlook this time, but really, it's a config default...). So this seems\nlike a perfect task for someone not too familiar with Git's codebase,\nbut still interested in contributing :)\n"},{"id":"454165","messageId":"xmqq8rrygq42.fsf@gitster.g","threadId":"57775","inReplyTo":"20220421194832.lshqkl3bogy2f2hy@eve","subject":"Re: Should sendemail.confirm default to always?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-21T20:04:29Z","receivedAt":"2022-04-21T20:04:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alyssa Ross <hi@alyssa.is> writes:\n\n> I was recently having a conversation with some people used to the\n> GitHub-style Pull Request workflow, who told me that they feel scared of\n> using git send-email in case they make a mistake and e.g. get the\n> recipients wrong, since they can't correct it after sending.  They can\n> resend, but if they do that they'll feel like they're bothering some\n> very busy people by having sent them the same message twice (regardless\n> of whether those people are actually bothered by it, it's scary).\n\nIf it truly makes sense to give a roadblock before sending to\nprevent mistakes, I wonder if making \"--dry-run\" the default is even\na better idea.  Getting \"are you sure [y/n]?\" and saying \"yes\" out\nof inertia is much more likely to happen than typing Ctrl-P on the\ncommand line to take the previous command (which did a dry-run by\ndefault) back on the command line and then adding \"--no-dry-run\" on\nthe command line to allow the command to actually send out the\nfiles.\n\nAnother idea is to forbid the form of \"git send-email\" invocation\nthat internally runs format-patch by default and force users to\nprepare format-patch into files beforehand.  Doing the format-patch\nas a completely separate step means that the user has a final chance\nto proofread the log messages (and correct them as needed) while\nadding and verifying CC's, and removes the pressure of \"pressing\nthis button is a point of no return; did I catch all the\nembarrassing mistakes?\" at the last second.\n"},{"id":"454177","messageId":"20220421203757.btisgy3bit4iboxv@eve","threadId":"57775","inReplyTo":"xmqq8rrygq42.fsf@gitster.g","subject":"Re: Should sendemail.confirm default to always?","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2022-04-21T20:37:57Z","receivedAt":"2022-04-21T20:38:10Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"On Thu, Apr 21, 2022 at 01:04:29PM -0700, Junio C Hamano wrote:\n> Alyssa Ross <hi@alyssa.is> writes:\n>\n> > I was recently having a conversation with some people used to the\n> > GitHub-style Pull Request workflow, who told me that they feel scared of\n> > using git send-email in case they make a mistake and e.g. get the\n> > recipients wrong, since they can't correct it after sending.  They can\n> > resend, but if they do that they'll feel like they're bothering some\n> > very busy people by having sent them the same message twice (regardless\n> > of whether those people are actually bothered by it, it's scary).\n>\n> If it truly makes sense to give a roadblock before sending to\n> prevent mistakes, I wonder if making \"--dry-run\" the default is even\n> a better idea.  Getting \"are you sure [y/n]?\" and saying \"yes\" out\n> of inertia is much more likely to happen than typing Ctrl-P on the\n> command line to take the previous command (which did a dry-run by\n> default) back on the command line and then adding \"--no-dry-run\" on\n> the command line to allow the command to actually send out the\n> files.\n\nIn all the time I've been using sendemail.confirm = always, I've never\naccidentally said \"yes\".  I'd be curious whether Ævar has, since they\nalso said they've used it for some time.\n\nI think always confirming is better than --dry-run because it allows\nmaking a decision for each message in a series, and because it makes it\neasy to insert commentary.  (If you end up sending the first few\nmessages in a series, then deciding not to send the rest before fixing\nsomething, the man page is good enough that it's possible to figure out\nhow to resume sending, in my experience.)\n\nIf you had to pass --no-dry-run every time, I'd worry about that being\nreplayed unthinkingly from shell history, defeating the purpose.  By\ncontrast, interactive per-message confirmation won't end up with the\nbypass being automatically saved in shell history.\n\n> Another idea is to forbid the form of \"git send-email\" invocation\n> that internally runs format-patch by default and force users to\n> prepare format-patch into files beforehand.  Doing the format-patch\n> as a completely separate step means that the user has a final chance\n> to proofread the log messages (and correct them as needed) while\n> adding and verifying CC's, and removes the pressure of \"pressing\n> this button is a point of no return; did I catch all the\n> embarrassing mistakes?\" at the last second.\n\nI thought about that, but I don't think it would be as good either,\nbecause it's difficult to predict what the final set of recipients will\nbe just from looking at the patch files — if I recall correctly,\nautomatic CCs (from trailers, cccmd, etc.) aren't added until send-email\ntime.  So even though I often run format-patch beforehand, I'm still\ngrateful to be prompted before each message.\n\nI also think that encouraging novices to format-patch first would make\nthe workflow seem even more arcane and confusing.  I definitely found it\nvery strange the first time I encountered it (more so than all-in-one\nsend-email).\n"},{"id":"454188","messageId":"xmqqwnfids7y.fsf@gitster.g","threadId":"57775","inReplyTo":"220421.86tuam5hoi.gmgdl@evledraar.gmail.com","subject":"Re: Should sendemail.confirm default to always?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-21T21:47:13Z","receivedAt":"2022-04-21T21:47:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> .... As always the real work is updating docs, running the tests\n> etc., digging up ML discussions to see if there's been any past\n> arguments for/against it etc.\n\nI agree with this part.  The code change itself may be easy, but it\ntakes a lot of work and moderate amount of help from a long timer or\ntwo.\n\n"},{"id":"454193","messageId":"20220421223843.6z3y4bnrbu76erhk@eve","threadId":"57775","inReplyTo":"220421.86tuam5hoi.gmgdl@evledraar.gmail.com","subject":"Failures in t9001-send-email","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2022-04-21T22:38:43Z","receivedAt":"2022-04-21T22:38:52Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"> I think a patch to do that would be worth having/reviewing (hint\n> hint!). As always the real work is updating docs, running the tests\n> etc., digging up ML discussions to see if there's been any past\n> arguments for/against it etc.\n>\n> In this case the code change itself should be trivial (I honestly didn't\n> look this time, but really, it's a config default...). So this seems\n> like a perfect task for someone not too familiar with Git's codebase,\n> but still interested in contributing :)\n\nI thought I'd have a go at a patch, but I wasn't able to get the tests\nrunning:\n\n    prove ./t9001-send-email.sh\n    ./t9001-send-email.sh .. Dubious, test returned 1 (wstat 256, 0x100)\n    Failed 15/188 subtests\n      (less 1 skipped subtest: 172 okay)\n\n    Test Summary Report\n    -------------------\n    ./t9001-send-email.sh (Wstat: 256 Tests: 188 Failed: 15)\n      Failed tests:  27, 51, 78-84, 123, 147-150, 185\n      Non-zero exit status: 1\n    Files=1, Tests=188, 17 wallclock secs ( 0.06 usr  0.01 sys + 11.66 cusr  5.37 csys = 17.10 CPU)\n    Result: FAIL\n\nI had a look at the tests to try to guess what was wrong, but I didn't\ncome up with anything.  Any ideas?  When I run make test, every other\ntest is fine, it's just the send-email tests that are problematic.\n\n(My git source tree is v2.36.0.)\n"},{"id":"454200","messageId":"024e01d855d6$35003d00$9f00b700$@nexbridge.com","threadId":"57775","inReplyTo":"20220421223843.6z3y4bnrbu76erhk@eve","subject":"RE: Failures in t9001-send-email","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-21T23:19:04Z","receivedAt":"2022-04-21T23:19:16Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 21, 2022 6:39 PM, Alyssa Ross wrote:\n>> I think a patch to do that would be worth having/reviewing (hint\n>> hint!). As always the real work is updating docs, running the tests\n>> etc., digging up ML discussions to see if there's been any past\n>> arguments for/against it etc.\n>>\n>> In this case the code change itself should be trivial (I honestly\n>> didn't look this time, but really, it's a config default...). So this\n>> seems like a perfect task for someone not too familiar with Git's\n>> codebase, but still interested in contributing :)\n>\n>I thought I'd have a go at a patch, but I wasn't able to get the tests\n>running:\n>\n>    prove ./t9001-send-email.sh\n>    ./t9001-send-email.sh .. Dubious, test returned 1 (wstat 256, 0x100)\n>    Failed 15/188 subtests\n>      (less 1 skipped subtest: 172 okay)\n>\n>    Test Summary Report\n>    -------------------\n>    ./t9001-send-email.sh (Wstat: 256 Tests: 188 Failed: 15)\n>      Failed tests:  27, 51, 78-84, 123, 147-150, 185\n>      Non-zero exit status: 1\n>    Files=1, Tests=188, 17 wallclock secs ( 0.06 usr  0.01 sys + 11.66 cusr\n5.37 csys =\n>17.10 CPU)\n>    Result: FAIL\n>\n>I had a look at the tests to try to guess what was wrong, but I didn't come\nup with\n>anything.  Any ideas?  When I run make test, every other test is fine, it's\njust the\n>send-email tests that are problematic.\n\nI have the same issue on NonStop. Not sure why, other than our sendmail is\nmassively broken.\n--Randall\n\n"},{"id":"454221","messageId":"36a43fbb-92af-3718-f2fb-51645564a961@kdbg.org","threadId":"57775","inReplyTo":"20220421223843.6z3y4bnrbu76erhk@eve","subject":"Re: Failures in t9001-send-email","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2022-04-22T05:40:07Z","receivedAt":"2022-04-22T05:40:25Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 22.04.22 um 00:38 schrieb Alyssa Ross:\n> I thought I'd have a go at a patch, but I wasn't able to get the tests\n> running:\n> \n>     prove ./t9001-send-email.sh\n>     ./t9001-send-email.sh .. Dubious, test returned 1 (wstat 256, 0x100)\n>     Failed 15/188 subtests\n> [...]\n> \n> I had a look at the tests to try to guess what was wrong, but I didn't\n> come up with anything.  Any ideas?\n\nYou run ./t9001-send-email.sh (without `prove`). Add -v to see some\nverbiage from the tests, throw in -i to have it stop at the first\nfailure (so you don't have to scroll back to find it), and add -x for\nadditional traces of commands that the shell executes (to see the exact\ncommand that failed).\n\nIFAIC, I always go all in, i.e., either all or none of -v -i -x.\n\n-- Hannes\n"},{"id":"454225","messageId":"xmqq7d7hd31g.fsf@gitster.g","threadId":"57775","inReplyTo":"36a43fbb-92af-3718-f2fb-51645564a961@kdbg.org","subject":"Re: Failures in t9001-send-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-22T06:51:07Z","receivedAt":"2022-04-22T06:51:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j6t@kdbg.org> writes:\n\n>> I had a look at the tests to try to guess what was wrong, but I didn't\n>> come up with anything.  Any ideas?\n>\n> You run ./t9001-send-email.sh (without `prove`). Add -v to see some\n> verbiage from the tests, throw in -i to have it stop at the first\n> failure (so you don't have to scroll back to find it), and add -x for\n> additional traces of commands that the shell executes (to see the exact\n> command that failed).\n>\n> IFAIC, I always go all in, i.e., either all or none of -v -i -x.\n\nGood suggestion.\n\nI rarely (if ever) use \"-x\" myself but another useful thing to know,\nwhile learning how the existing test works (i.e. studying a working\ntest, not debugging a broken test) is to use \"-d\", possibly together\nwith \"-v\", which refrains from removing the trash directory.  Then\nyou can go in and examine the state of the test repository the tests\nleft.\n\nThanks.\n"},{"id":"454226","messageId":"20220422075633.rpiteai4uwdd6jvr@eve","threadId":"57775","inReplyTo":"024e01d855d6$35003d00$9f00b700$@nexbridge.com","subject":"Re: Failures in t9001-send-email","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2022-04-22T07:56:33Z","receivedAt":"2022-04-22T07:57:53Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"On Thu, Apr 21, 2022 at 07:19:04PM -0400, rsbecker@nexbridge.com wrote:\n> On April 21, 2022 6:39 PM, Alyssa Ross wrote:\n> >I thought I'd have a go at a patch, but I wasn't able to get the tests\n> >running:\n> >\n> >    prove ./t9001-send-email.sh\n> >    ./t9001-send-email.sh .. Dubious, test returned 1 (wstat 256, 0x100)\n> >    Failed 15/188 subtests\n> >      (less 1 skipped subtest: 172 okay)\n> >\n> >    Test Summary Report\n> >    -------------------\n> >    ./t9001-send-email.sh (Wstat: 256 Tests: 188 Failed: 15)\n> >      Failed tests:  27, 51, 78-84, 123, 147-150, 185\n> >      Non-zero exit status: 1\n> >    Files=1, Tests=188, 17 wallclock secs ( 0.06 usr  0.01 sys + 11.66 cusr\n> 5.37 csys =\n> >17.10 CPU)\n> >    Result: FAIL\n> >\n> >I had a look at the tests to try to guess what was wrong, but I didn't come\n> up with\n> >anything.  Any ideas?  When I run make test, every other test is fine, it's\n> just the\n> >send-email tests that are problematic.\n>\n> I have the same issue on NonStop. Not sure why, other than our sendmail is\n> massively broken.\n> --Randall\n\nFor me the solution was to make Term::ReadLine available in my\ndevelopment environment.  I hope that helps you too!\n"},{"id":"454227","messageId":"20220422080052.diovj33bfnra62uv@eve","threadId":"57775","inReplyTo":"xmqq7d7hd31g.fsf@gitster.g","subject":"Re: Failures in t9001-send-email","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2022-04-22T08:00:52Z","receivedAt":"2022-04-22T08:00:58Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"On Thu, Apr 21, 2022 at 11:51:07PM -0700, Junio C Hamano wrote:\n> Johannes Sixt <j6t@kdbg.org> writes:\n>\n> >> I had a look at the tests to try to guess what was wrong, but I didn't\n> >> come up with anything.  Any ideas?\n> >\n> > You run ./t9001-send-email.sh (without `prove`). Add -v to see some\n> > verbiage from the tests, throw in -i to have it stop at the first\n> > failure (so you don't have to scroll back to find it), and add -x for\n> > additional traces of commands that the shell executes (to see the exact\n> > command that failed).\n> >\n> > IFAIC, I always go all in, i.e., either all or none of -v -i -x.\n>\n> Good suggestion.\n>\n> I rarely (if ever) use \"-x\" myself but another useful thing to know,\n> while learning how the existing test works (i.e. studying a working\n> test, not debugging a broken test) is to use \"-d\", possibly together\n> with \"-v\", which refrains from removing the trash directory.  Then\n> you can go in and examine the state of the test repository the tests\n> left.\n\nThank you both for these tips.\n\nI was able to determine the issue by running the test with -vixd,\nnoticing which command failed, and then trying to set up my shell\nenvironment manually to match the test's (PATH, PERLLIB,\ncommitter/author info, etc.), and ran the same command with the leftover\ntrash directory.  This produced error output that didn't show up when I\nwas running the test (not sure why) that gave me a line number in\ngit-send-email.perl.  I noticed that it was trying to load\nTerm::ReadLine near that line, and I didn't have that installed in my\ndevelopment environment.\n\nNow that I have that installed, all send-email tests pass.\nThanks again!\n"},{"id":"454229","messageId":"20220422083629.1404989-1-hi@alyssa.is","threadId":"57775","inReplyTo":"220421.86tuam5hoi.gmgdl@evledraar.gmail.com","subject":"[PATCH] send-email: always confirm by default","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2022-04-22T08:36:29Z","receivedAt":"2022-04-22T08:36:50Z","isPatch":true,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"For novice users, it can be very intimidating for git send-email to send\noff a lot of mail without prompting for confirmation.  These users are\nlikely to not know it's even possible to configure git to behave\ndifferently.  So let's set a novice-friendly default — expert users who\ndon't need to be prompted every time will be able to set\nsendemail.confirm to their preference, although from my small sample it\nsounds plenty of expert users already rely on sendemail.confirm =\nalways.\n\nI think this is a better idea than defaulting to --dry-run, because\nhaving to specify on the command line that you _really_ want to send the\npatches now would mean the --no-dry-run version would quickly end up\nbeing replayed unthinkingly from shell history, and because always\nconfirming has the nice side effect of making it easy to add patch\ncommentary.\n\nI also think this approach is better than forbidding the all-in-one\nformat-patch + send-email, because it wouldn't give an accurate preview\nof recipients, because automatic CCs are added by send-email, not\nformat-patch.  Additionally, teaching git send-email is hard enough\nwithout having to also teach format-patch, and to make sure to clean up\nafterwards, etc!\n\nSigned-off-by: Alyssa Ross <hi@alyssa.is>\n---\n\n[[ Whoops, sent to the list this time! ]]\n\nÆvar, thanks for encouraging me to send a patch.  At your suggestion,\nI've trawled through the list archives looking for any previous\ndiscussion of this default, but I didn't find anything.\n\n Documentation/git-send-email.txt |  3 +--\n git-send-email.perl              |  2 +-\n t/t9001-send-email.sh            | 14 ++++----------\n 3 files changed, 6 insertions(+), 13 deletions(-)\n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 41cd8cb424..b791d83bb7 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -407,8 +407,7 @@ Administering\n --\n +\n Default is the value of `sendemail.confirm` configuration value; if that\n-is unspecified, default to 'auto' unless any of the suppress options\n-have been specified, in which case default to 'compose'.\n+is unspecified, default to 'always'.\n \n --dry-run::\n \tDo everything except actually send the emails.\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 5861e99a6e..4aa7d83cdc 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -606,7 +606,7 @@ sub config_regexp {\n # Set confirm's default value\n my $confirm_unconfigured = !defined $confirm;\n if ($confirm_unconfigured) {\n-\t$confirm = scalar %suppress_cc ? 'compose' : 'auto';\n+\t$confirm = 'always';\n };\n # Please update $__git_send_email_confirm_options in\n # git-completion.bash when you add new options.\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 42694fe584..e11730f3dc 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -74,8 +74,8 @@ check_no_confirm () {\n \treturn 0\n }\n \n-test_expect_success $PREREQ 'No confirm with --suppress-cc' '\n-\ttest_no_confirm --suppress-cc=sob &&\n+test_expect_success $PREREQ 'No confirm with --confirm=compose --suppress-cc' '\n+\ttest_no_confirm --confirm=compose --suppress-cc=sob &&\n \tcheck_no_confirm\n '\n \n@@ -1032,16 +1032,10 @@ test_expect_success $PREREQ '--confirm=compose' '\n \ttest_confirm --confirm=compose --compose\n '\n \n-test_expect_success $PREREQ 'confirm by default (due to cc)' '\n+test_expect_success $PREREQ 'confirm by default' '\n \ttest_when_finished git config sendemail.confirm never &&\n \tgit config --unset sendemail.confirm &&\n-\ttest_confirm\n-'\n-\n-test_expect_success $PREREQ 'confirm by default (due to --compose)' '\n-\ttest_when_finished git config sendemail.confirm never &&\n-\tgit config --unset sendemail.confirm &&\n-\ttest_confirm --suppress-cc=all --compose\n+\ttest_confirm --suppress-cc=all\n '\n \n test_expect_success $PREREQ 'confirm detects EOF (inform assumes y)' '\n\nbase-commit: 6cd33dceed60949e2dbc32e3f0f5e67c4c882e1e\n-- \n2.35.1\n\n"},{"id":"454252","messageId":"028501d85635$99790410$cc6b0c30$@nexbridge.com","threadId":"57775","inReplyTo":"20220422075633.rpiteai4uwdd6jvr@eve","subject":"RE: Failures in t9001-send-email","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-22T10:41:55Z","receivedAt":"2022-04-22T10:42:09Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 22, 2022 3:57 AM, Alyssa Ross wrote:\n>On Thu, Apr 21, 2022 at 07:19:04PM -0400, rsbecker@nexbridge.com wrote:\n>> On April 21, 2022 6:39 PM, Alyssa Ross wrote:\n>> >I thought I'd have a go at a patch, but I wasn't able to get the\n>> >tests\n>> >running:\n>> >\n>> >    prove ./t9001-send-email.sh\n>> >    ./t9001-send-email.sh .. Dubious, test returned 1 (wstat 256, 0x100)\n>> >    Failed 15/188 subtests\n>> >      (less 1 skipped subtest: 172 okay)\n>> >\n>> >    Test Summary Report\n>> >    -------------------\n>> >    ./t9001-send-email.sh (Wstat: 256 Tests: 188 Failed: 15)\n>> >      Failed tests:  27, 51, 78-84, 123, 147-150, 185\n>> >      Non-zero exit status: 1\n>> >    Files=1, Tests=188, 17 wallclock secs ( 0.06 usr  0.01 sys +\n>> > 11.66 cusr\n>> 5.37 csys =\n>> >17.10 CPU)\n>> >    Result: FAIL\n>> >\n>> >I had a look at the tests to try to guess what was wrong, but I\n>> >didn't come\n>> up with\n>> >anything.  Any ideas?  When I run make test, every other test is\n>> >fine, it's\n>> just the\n>> >send-email tests that are problematic.\n>>\n>> I have the same issue on NonStop. Not sure why, other than our\n>> sendmail is massively broken.\n>> --Randall\n>\n>For me the solution was to make Term::ReadLine available in my development\n>environment.  I hope that helps you too!\n\nThanks. I will look into this.\n--Randall\n\n"},{"id":"454254","messageId":"220422.86zgkd4b1l.gmgdl@evledraar.gmail.com","threadId":"57775","inReplyTo":"20220422083629.1404989-1-hi@alyssa.is","subject":"Re: [PATCH] send-email: always confirm by default","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-22T11:16:46Z","receivedAt":"2022-04-22T11:23:09Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 22 2022, Alyssa Ross wrote:\n\n> [[ Whoops, sent to the list this time! ]]\n\nIt is somewhat ironic to have an accidental E-Mail send given the patch\nsubject :)\n\n> Ævar, thanks for encouraging me to send a patch.  At your suggestion,\n> I've trawled through the list archives looking for any previous\n> discussion of this default, but I didn't find anything.\n\nGlad to see a follow-up to this. Thanks.\n\n>  Documentation/git-send-email.txt |  3 +--\n>  git-send-email.perl              |  2 +-\n>  t/t9001-send-email.sh            | 14 ++++----------\n>  3 files changed, 6 insertions(+), 13 deletions(-)\n>\n> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\n> index 41cd8cb424..b791d83bb7 100644\n> --- a/Documentation/git-send-email.txt\n> +++ b/Documentation/git-send-email.txt\n> @@ -407,8 +407,7 @@ Administering\n>  --\n>  +\n>  Default is the value of `sendemail.confirm` configuration value; if that\n> -is unspecified, default to 'auto' unless any of the suppress options\n> -have been specified, in which case default to 'compose'.\n> +is unspecified, default to 'always'.\n>  \n>  --dry-run::\n>  \tDo everything except actually send the emails.\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 5861e99a6e..4aa7d83cdc 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -606,7 +606,7 @@ sub config_regexp {\n>  # Set confirm's default value\n>  my $confirm_unconfigured = !defined $confirm;\n>  if ($confirm_unconfigured) {\n> -\t$confirm = scalar %suppress_cc ? 'compose' : 'auto';\n> +\t$confirm = 'always';\n>  };\n\n\nI squinted a bit at this and wonder now that we don't have that ternary\nwhether we can simplify this a bit.\n\nIsn't this the same now as:\n\n    my $confirm_unconfigured = !defined $confirm;\n    $confirm ||= 'always'; # well, defined-or, but I don't think we care here.\n\nBut probably not worth obsessing over it... :) I.e. it seems fine as-is.\n\n> -test_expect_success $PREREQ 'No confirm with --suppress-cc' '\n> -\ttest_no_confirm --suppress-cc=sob &&\n> +test_expect_success $PREREQ 'No confirm with --confirm=compose --suppress-cc' '\n> +\ttest_no_confirm --confirm=compose --suppress-cc=sob &&\n>  \tcheck_no_confirm\n>  '\n>  \n> @@ -1032,16 +1032,10 @@ test_expect_success $PREREQ '--confirm=compose' '\n>  \ttest_confirm --confirm=compose --compose\n>  '\n>  \n> -test_expect_success $PREREQ 'confirm by default (due to cc)' '\n> +test_expect_success $PREREQ 'confirm by default' '\n>  \ttest_when_finished git config sendemail.confirm never &&\n>  \tgit config --unset sendemail.confirm &&\n> -\ttest_confirm\n> -'\n> -\n> -test_expect_success $PREREQ 'confirm by default (due to --compose)' '\n> -\ttest_when_finished git config sendemail.confirm never &&\n> -\tgit config --unset sendemail.confirm &&\n> -\ttest_confirm --suppress-cc=all --compose\n> +\ttest_confirm --suppress-cc=all\n>  '\n\nIt looks like we're losing some coverage here (I may be wrong). I.e. yes\nwe should update tests and descriptions, but for lines that test what we\ndid with a given command-line before let's turn those into tests that\npositively assert what we do now.\n\nI.e. we lost the \"--suppress-cc=sob\" test (with no other option), and\nalso \"--suppress-cc=all --compose\"?\n"},{"id":"454266","messageId":"xmqq7d7havuy.fsf@gitster.g","threadId":"57775","inReplyTo":"20220422083629.1404989-1-hi@alyssa.is","subject":"Re: [PATCH] send-email: always confirm by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-22T17:09:09Z","receivedAt":"2022-04-22T17:09:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alyssa Ross <hi@alyssa.is> writes:\n\n> For novice users, it can be very intimidating for git send-email to send\n> off a lot of mail without prompting for confirmation.  These users are\n> likely to not know it's even possible to configure git to behave\n> differently.  So let's set a novice-friendly default — expert users who\n> don't need to be prompted every time will be able to set\n> sendemail.confirm to their preference, although from my small sample it\n> sounds plenty of expert users already rely on sendemail.confirm =\n> always.\n\nOne thing the current behaviour of \"confirm\" makes a bad end-user\nexperience for recipients is that you can individually say \"no, this\nmessage has wrong address on the CC line, do not send it\" and the\nreceivers end up seeing [1/4] [2/4] [4/4] and left wondering what\nhappend to [3/4], until [3/4] alone is resent.\n\nIterating over messages and letting the user examine the headers for\neach of them is perfectly fine, but it would make it much nicer to\nrecipients if the choices are collected first and then even a single\nNO stops the entire series from getting sent.\n\n\t[Side note] As with everything else in Git, which is a tool\n\tto help people interact with each other better, we give\n\tpriority to avoid wasting time of the more populous side,\n\tand naturally, we should aim to make it less annoying to\n\treceivers even if it means that the sender needs to spend a\n\tbit more time to send the right things to the right people.\n\nAnd making \"confirm\" the default before it is fixed may make it\neasier to annoy receivers.\n\n> I also think this approach is better than forbidding the all-in-one\n> format-patch + send-email, because it wouldn't give an accurate preview\n> of recipients, because automatic CCs are added by send-email, not\n> format-patch.\n\nI do not think this part matches reality.  format-patch alone does\nnot manage CC or To at all.  What the separation of send-email and\nformat-patch does is to train people to actually proofread what they\nare going to send out.  Being able to add Cc: and To: at the header\npart (instead of adding Cc: to trailers and have send-email to pick\nthem up, which is error prone and forcing you to advocate this\ndefault change so that you can check at the last minute) of the\ngenerated patch text is icing on the cake ;-)\n\n>  if ($confirm_unconfigured) {\n> -\t$confirm = scalar %suppress_cc ? 'compose' : 'auto';\n> +\t$confirm = 'always';\n\nThis got a lot simpler.  I've always wondered why this \"if suppress\nCC is there, then default to 'compose' and otherwise 'auto'\" makes a\nsensible default.\n\n> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\n> index 42694fe584..e11730f3dc 100755\n> --- a/t/t9001-send-email.sh\n> +++ b/t/t9001-send-email.sh\n> @@ -74,8 +74,8 @@ check_no_confirm () {\n>  \treturn 0\n>  }\n>  \n> -test_expect_success $PREREQ 'No confirm with --suppress-cc' '\n> -\ttest_no_confirm --suppress-cc=sob &&\n> +test_expect_success $PREREQ 'No confirm with --confirm=compose --suppress-cc' '\n> +\ttest_no_confirm --confirm=compose --suppress-cc=sob &&\n>  \tcheck_no_confirm\n>  '\n>  \n> @@ -1032,16 +1032,10 @@ test_expect_success $PREREQ '--confirm=compose' '\n>  \ttest_confirm --confirm=compose --compose\n>  '\n>  \n> -test_expect_success $PREREQ 'confirm by default (due to cc)' '\n> +test_expect_success $PREREQ 'confirm by default' '\n>  \ttest_when_finished git config sendemail.confirm never &&\n>  \tgit config --unset sendemail.confirm &&\n> -\ttest_confirm\n> -'\n> -\n> -test_expect_success $PREREQ 'confirm by default (due to --compose)' '\n> -\ttest_when_finished git config sendemail.confirm never &&\n> -\tgit config --unset sendemail.confirm &&\n> -\ttest_confirm --suppress-cc=all --compose\n> +\ttest_confirm --suppress-cc=all\n>  '\n\nIt is curious that the change to the test this patch adds are only\nto adjust to the fallout the change of the default causes, and there\nis no new test to make sure that unconfigured sendemail.confirm\ntriggers confirmation dialogue.\n\nI still have reservations, as I would eventually have to sell those\nexisting users that this usability regression [*1*] is worth having\nin the new release.  It will need a large backward-compatibility note\nin the Release Notes, at least.\n\nBut assuming that you can help convince these few dozens of existing\nGit users out there that it is worth doing, the implementation seems\ncorrect to me.\n\nThanks.\n\n\n[Footnote]\n\n*1* The existing users will be surprised by sudden appearance of\nunexpected confirmation dialogue, which they may have never seen,\nand have to decide\n\n (1) keep saying \"yes\" to send out the current series, or\n (2) abort, read release notes and finally configure the\n     sendemail.confirm away before resending\n\nsoon after updating their Git.  They will be extremely annoyed if\nthat happens when they were about to send out a large series.\n"}]}