Oswald Buddenhagen <oswald.buddenhagen@xxxxxx> 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? The end-users (not necessarily all of them, of course)
have been happily using the command and have appreciated not having
to see non-zero exit code after skipping some messages. I wonder if
this should be hidden behind an opt-in command line option and possibly
a configuration variable that defaults to "no".
> 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.
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). 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.
> 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.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index affbb88509..cd4db84b7f 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 cancelled on first message already
> + exit(11);
> + }
> +}
OK. As log as we won't start doing
while (loop) {
$file = shift @files;
send $file;
}
this will keep working fine, and the logic is very clear to see.
Thanks. Will queue but expect at least some documentation updates.
