| Message ID | 20230821170720.577835-1-oswald.buddenhagen@gmx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v5] send-email: prompt-dependent exit codes | expand |
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes: > to opt-in (which is obviously the status quo, and is likely to persist > in most cases) is potentially at least somewhat serious. What's the weaseling "potentially at least somewhat" phrase about? Quite honestly, it makes it apparent that the patch is trying to make a change that cannot be justified and makes it lose all the remaining credibility. The users have lived with the current behaviour practically forever in Git's timescale and not changing the default and letting them "live with" the status quo cannot be any _serious_ at all. Will replace what I had kept but out of 'seen', as the changed parts of the patch are definite improvements, but I do not think I want to merge it without starting this as an optional feature. Thanks.
On Mon, Aug 21, 2023 at 10:57:05AM -0700, Junio C Hamano wrote: >Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes: > >> to opt-in (which is obviously the status quo, and is likely to persist >> in most cases) is potentially at least somewhat serious. > >What's the weaseling "potentially at least somewhat" phrase about? > i think that mails not being sent (timely, until somebody notices the mistake) is "at least somewhat serious". at least serious enough to justify a few people having to make a minor ajustment to their scripts to confirm that they really want the old behavior. regards
Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes: > Proposed content for RelNotes: > > * "git send-email" now reports interactive cancellation via a distinct > non-zero exit status. Callers which do not consider this situation an > error need to be adjusted. If we still want to deliberately break folks with this change, we should not blame users for becoming accustomed to the traditional behaviour and pretend as if burdening them to change their scripts is within our rights. We should be a lot more apologetic in the backward compatibility notes than what you wrote in the above. Having said that, quite honestly, I do not think this new behaviour deserves to be a new default from the day one, with need for an apology to existing users by the project. Given that the users have lived with the current behaviour practically forever in Git's timescale and that not changing the default and letting them "live with" the status quo cannot cause any serious problem, I cannot stand behind such a default change myself. It should be a new feature that is opt-in, just like any other new and useful feature.. By the way, I just noticed that the test will not pass on BSD derived systems. Something like this need to be squashed in if we want to proceed further. --- >8 --- squash --- >8 --- Subject: [PATCH] SQUASH??? Sending "wc -l" output to a file and expecting that it has a run of digits with terminating newline and nothing else is prone to break on BSD derived systems, including macOS. --- t/t9001-send-email.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index 64f9c7c154..8323783963 100755 --- a/t/t9001-send-email.sh +++ b/t/t9001-send-email.sh @@ -1198,7 +1198,7 @@ test_confirm_many () { -2 <replies echo $? >exit_sts test_cmp expected_sts exit_sts || return 1 - ls commandline* 2>/dev/null | wc -l >num_mails + echo $(ls commandline* 2>/dev/null | wc -l) >num_mails test_cmp expected_num num_mails || return 1 }
On Tue, Aug 29, 2023 at 05:46:32PM -0700, Junio C Hamano wrote: >Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes: > >> Proposed content for RelNotes: >> >> * "git send-email" now reports interactive cancellation via a distinct >> non-zero exit status. Callers which do not consider this situation an >> error need to be adjusted. > >If we still want to deliberately break folks with this change, we >should not blame users for becoming accustomed to the traditional >behaviour and pretend as if burdening them to change their scripts >is within our rights. We should be a lot more apologetic in the >backward compatibility notes than what you wrote in the above. > i find this deference mind-boggling. i'm sure you're somewhat cautious because you're on the frontline when people complain, and *someone* will _always_ complain when things change. however, it's completely unreasonable to let this dictate one's possibilities. there is a trade-off between the cost of change and the cost of non-change. >Given that the users have >lived with the current behaviour practically forever in Git's >timescale and that not changing the default and letting them "live >with" the status quo cannot cause any serious problem, I cannot >stand behind such a default change myself. > the exit code really only matters when there is a wrapper which decides significant follow-up actions based on it (that is, doesn't exit right afterwards anyway). i don't think many such scripts exist for git-send-email. those which do will most likely suppress interaction. which is why nobody else complained yet. and also why likely nobody will complain if we change it. the few people that will notice at all will most likely welcome the change, as i would. >It should be a new feature that is opt-in, > do as you like, but i won't spend the time on roughly doubling the size of the patch, nor on dealing with this being an opt-in (i don't want a hard dep on a new git version in the near term), and i won't contribute to sabotaging the discovery of hidden bugs. >just like any other new and useful feature.. > not reporting a significant event is a bug. >Subject: [PATCH] SQUASH??? > yes, please. regards
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 492a82323d..766c190ef0 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -480,6 +480,15 @@ include::includes/cmd-config-section-all.txt[] include::config/sendemail.txt[] + +EXIT STATUS +----------- + +Zero is returned when all specified patches were sent, while 1 is returned +when an error occurs. 10 is returned if the user interactively skips sending +only some patches, and 11 if they skip all patches. + + EXAMPLES -------- Use gmail as the smtp server diff --git a/git-send-email.perl b/git-send-email.perl index affbb88509..2c62de07bc 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -256,6 +256,26 @@ sub system_or_die { die $msg if $msg; } +my $sent_files = 0; + +sub do_exit { + if ($sent_files == @files) { + # All specified messages were sent + exit(0); + } elsif ($sent_files) { + # At least some messages were sent + exit(10); + } else { + # User skipped all messages or quit before sending the first one + exit(11); + } +} + +sub do_quit { + cleanup_compose_files(); + do_exit(); +} + sub do_edit { if (!defined($editor)) { $editor = Git::command_oneline('var', 'GIT_EDITOR'); @@ -1195,8 +1215,7 @@ sub validate_address { if (/^d/i) { return undef; } elsif (/^q/i) { - cleanup_compose_files(); - exit(0); + do_quit(); } $address = ask("$to_whom ", default => "", @@ -1619,8 +1638,7 @@ sub send_message { } elsif (/^e/i) { return -1; } elsif (/^q/i) { - cleanup_compose_files(); - exit(0); + do_quit(); } elsif (/^a/i) { $confirm = 'never'; } @@ -2001,6 +2019,10 @@ sub process_file { return 0; } + if ($message_was_sent) { + $sent_files++; + } + # set up for the next message if ($thread) { if ($message_was_sent && @@ -2278,3 +2300,5 @@ sub body_or_subject_has_nonascii { } return 0; } + +do_exit(); diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index 48bf0af2ee..64f9c7c154 100755 --- a/t/t9001-send-email.sh +++ b/t/t9001-send-email.sh @@ -1187,6 +1187,42 @@ test_expect_success $PREREQ 'confirm does not loop forever' ' $patches ' +test_confirm_many () { + clean_fake_sendmail + GIT_SEND_EMAIL_NOTTY=1 \ + git send-email \ + --confirm=auto \ + --from="Example <nobody@example.com>" \ + --to=nobody@example.com \ + --smtp-server="$(pwd)/fake.sendmail" \ + -2 <replies + echo $? >exit_sts + test_cmp expected_sts exit_sts || return 1 + ls commandline* 2>/dev/null | wc -l >num_mails + test_cmp expected_num num_mails || return 1 +} + +test_expect_success $PREREQ 'interactively skip none' ' + (echo y && echo y) >replies && + echo 0 >expected_sts && + echo 2 >expected_num && + test_confirm_many +' + +test_expect_success $PREREQ 'interactively skip some' ' + (echo n && echo y) >replies && + echo 10 >expected_sts && + echo 1 >expected_num && + test_confirm_many +' + +test_expect_success $PREREQ 'interactively skip all' ' + (echo n && echo n) >replies && + echo 11 >expected_sts && + echo 0 >expected_num && + test_confirm_many +' + test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' ' clean_fake_sendmail && rm -fr outdir &&
It seems very likely that most scripted callers would want to know when (some) mails were interactively requested to be not sent, so indicate this situation with a non-zero exit code. We use 10/11, because these seem sufficiently distinct from "regular" error codes one would expect. This is technically a backwards-incompatible behavior change, and therefore would be safer to make opt-in. However, it is much easier to imagine that a scripting user simply didn't consider the possibility of an interactive cancellation, than that they really meant to ignore it. Also, the damage resulting from reporting the situation too eagerly is expected to be trivial, while the damage resulting from callers failing to opt-in (which is obviously the status quo, and is likely to persist in most cases) is potentially at least somewhat serious. This means that making it opt-in has an opportunity cost, and I think the trade-off favors making the new behavior unconditional. For interactive calls from the command line, interactive cancellation is arguably not unexpected, but a human user will be able to interpret the somewhat unusual exit code in light of their immediately preceding interactions just fine. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> --- Proposed content for RelNotes: * "git send-email" now reports interactive cancellation via a distinct non-zero exit status. Callers which do not consider this situation an error need to be adjusted. --- v5: - fix whitespace in tests' redirections - tweak commit message some more - tweak manual (notably, it now says "1" instead of "one", which is linguistically incorrect, but imo less confusing) - fix inaccuracy in a comment in do_exit() v4: - add tests (which also cover the partial confirmation behavior in the first place) - add docu - rework commit message again v3: - use a tally instead of flags after all, as my seemingly simple idea apparently requires lots of thinking to grasp fully - correct exit code when zero messages are to be sent. this cannot actually happen, as it induces an exit via usage() earlier on. - unfold nested ternary to save junio's sanity (who proved his point by unfolding it slightly incorrectly) - expand commit message v2: - fix do_quit() not resetting $sent_all Cc: Junio C Hamano <gitster@pobox.com> Cc: Phillip Wood <phillip.wood123@gmail.com> --- Documentation/git-send-email.txt | 9 ++++++++ git-send-email.perl | 32 ++++++++++++++++++++++++---- t/t9001-send-email.sh | 36 ++++++++++++++++++++++++++++++++ 3 files changed, 73 insertions(+), 4 deletions(-)