From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
Phillip Wood <phillip.wood123@gmail.com>
Subject: [PATCH v5] send-email: prompt-dependent exit codes
Date: Mon, 21 Aug 2023 19:07:20 +0200 [thread overview]
Message-ID: <20230821170720.577835-1-oswald.buddenhagen@gmx.de> (raw)
In-Reply-To: <xmqq5y5msmc0.fsf@gitster.g>
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(-)
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 &&
--
2.40.0.152.g15d061e6df
next prev parent reply other threads:[~2023-08-21 17:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 6:16 [PATCH v2] send-email: prompt-dependent exit codes Oswald Buddenhagen
2023-04-27 15:49 ` Junio C Hamano
2023-05-02 19:04 ` Felipe Contreras
2023-08-07 16:58 ` [PATCH v3] " Oswald Buddenhagen
2023-08-07 18:55 ` Junio C Hamano
2023-08-08 10:55 ` Oswald Buddenhagen
2023-08-08 16:08 ` Junio C Hamano
2023-08-08 19:11 ` Oswald Buddenhagen
2023-08-09 17:15 ` [PATCH v4] " Oswald Buddenhagen
2023-08-09 19:15 ` Junio C Hamano
2023-08-10 10:00 ` Oswald Buddenhagen
2023-08-10 19:56 ` Junio C Hamano
2023-08-11 12:11 ` Oswald Buddenhagen
2023-08-21 17:07 ` Oswald Buddenhagen [this message]
2023-08-21 17:57 ` [PATCH v5] " Junio C Hamano
2023-08-21 18:57 ` Oswald Buddenhagen
2023-08-30 0:46 ` Junio C Hamano
2023-08-30 10:06 ` Oswald Buddenhagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230821170720.577835-1-oswald.buddenhagen@gmx.de \
--to=oswald.buddenhagen@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).