Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx> writes:
> On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:
>> Do you have sendemail.to set in your local git config?
>
> I do and can't reproduce either; which version of git do you have this
> problem with?
Any recent version of git-send-email, I would say. The relevant
code snippets are:
my $prompting = 0;
if (!@initial_to && !defined $to_cmd) {
my $to = ask("$to_whom ",
default => "",
valid_re => qr/\@.*\./, confirm_only => 1);
push @initial_to, parse_address_line($to) if defined $to; #
$prompting++;
}
...
@initial_to = process_address_list(@initial_to);
@initial_cc = process_address_list(@initial_cc);
@initial_bcc = process_address_list(@initial_bcc);
if ($thread && !defined $initial_in_reply_to && $prompting) {
$initial_in_reply_to = ask(
__("Message-ID to be used as In-Reply-To for the first email (if any)? "),
default => "",
valid_re => qr/\@.*\./, confirm_only => 1);
}
where initial_to is set either from the command line or sendemail.to
configuration variable and before the control reaches this section
of the code. In addition to realizing "ah, To: address is not given
so we need to ask" and ask the to address, it says "since we have
already interatively asked the end-user anyway, we can and should
ask other things as well" by incrementing $prompting.
That feels both understandable and bogus at the same time. To:
is pretty much required (yes, you can use cc: and bcc: without any
address on To:, but that is not something you'd usually do to send
patches to mailing lists), so lack of it means either asking
interactively or aborting. But other things like in-reply-to are
optional, and tying the decision to prompt for them or not does not
feel OK.
