From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v3] send-email: prompt-dependent exit codes
Date: Tue, 8 Aug 2023 12:55:09 +0200 [thread overview]
Message-ID: <ZNIfDXJBqEVcHh+D@ugly> (raw)
In-Reply-To: <xmqqbkfifzry.fsf@gitster.g>
On Mon, Aug 07, 2023 at 11:55:29AM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>
>> From the perspective of a scripted caller, failure to send (some) mails
>> is an error even if it was interactively requested, so it should be
>> indicated by the exit code.
>
>I am not sure if unconditional change of exit code this late in the
>game.
> When was the interactive "no, do not send this one" feature
> introduced?
>
c1f2aa45b7 (add --confirm option and configuration setting, 2009-03-02),
and extended by 5c80afed02 (ask what to do with an invalid email
address, 2012-11-26), so basically it's been there forever.
>I wonder if this should be hidden behind an opt-in command line option
>and possibly a configuration variable that defaults to "no".
>
i wondered, too, but i think it isn't really worth it.
interactive users won't really care (see below), and most scripted users
presumably simply suppressed the condition by passing --confirm=never
and/or appropriate --suppress* options. others didn't notice (possibly
because of their config options), or ignored the problem, and therefore
have a good chance of being broken. some were unhappy about it, but
didn't bother reporting/patching it, which always constitutes the vast
majority of affected users. this still leaves us with a hypothetical
small set of wrapper scripts that _really_ want to remain ignorant of
messages being skipped. i think it's acceptable to expect them to adjust
to the (from their POV) false positives, as it should be mostly
harmless, and have the effect of getting some scripts fixed.
>> To make it somewhat specific, the exit code is 10 when only some
>> mails
>> were skipped, and 11 if the user quit on the first prompt.
>
>If 10 and 11 were *not* taken out of thin air, but there is a
>precedent to use these two values in e-mail related programs, please
>share. It may give us a good justification.
>
the numbers are indeed pulled out of thin air. the offset is chosen such
that it's sufficiently far off normally expected exit codes.
>With or without other people's precedents, and with or without
>making it conditional, the new behaviour must be documented, if the
>command has already a documentation (and it seems that there exists
>the Documentation/git-send-email.txt file).
>
ack, will add an EXIT STATUS section.
>It may be preferrable
>to protect the new feature with a test or two added to t9001 but it
>obviously depends on how hard you find testing interactive stuff is.
>
shouldn't be too hard; test_{,no_}confirm show how to do it.
>> For interactive calls from the command line, interactive cancellation is
>> arguably not really an error, but there the exit code will be more or
>> less ignored anyway.
>
>Not necessarily. Some people prefer to see it and show it in their
>command line prompt.
>
hence "mostly".
but users generally know what they did just a few secs ago, so likely
won't be bothered by the special exit code.
>Thanks. Will queue but expect at least some documentation updates.
>
do you want a followup, or a v4 to replace the commit?
regards
next prev parent reply other threads:[~2023-08-08 15:58 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 [this message]
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 ` [PATCH v5] " Oswald Buddenhagen
2023-08-21 17:57 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNIfDXJBqEVcHh+D@ugly \
--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.
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).