git/git-send-email.perl, branch v2.45.2

Merge branch 'tz/send-email-negatable-options'

2023-12-10T00:37:51Z

Newer versions of Getopt::Long started giving warnings against our (ab)use of it in "git send-email". Bump the minimum version requirement for Perl to 5.8.1 (from September 2002) to allow simplifying our implementation. * tz/send-email-negatable-options: send-email: avoid duplicate specification warnings perl: bump the required Perl version to 5.8.1 from 5.8.0

Merge branch 'tz/send-email-helpfix'

2023-11-20T00:57:22Z

Typoes in "git send-email -h" have been corrected. * tz/send-email-helpfix: send-email: remove stray characters from usage

send-email: avoid duplicate specification warnings

2023-11-16T22:26:34Z

A warning is issued for options which are specified more than once beginning with perl-Getopt-Long >= 2.55. In addition to causing users to see warnings, this results in test failures which compare the output. An example, from t9001-send-email.37: | +++ diff -u expect actual | --- expect 2023-11-14 10:38:23.854346488 +0000 | +++ actual 2023-11-14 10:38:23.848346466 +0000 | @@ -1,2 +1,7 @@ | +Duplicate specification "no-chain-reply-to" for option "no-chain-reply-to" | +Duplicate specification "to-cover|to-cover!" for option "to-cover" | +Duplicate specification "cc-cover|cc-cover!" for option "cc-cover" | +Duplicate specification "no-thread" for option "no-thread" | +Duplicate specification "no-to-cover" for option "no-to-cover" | fatal: longline.patch:35 is longer than 998 characters | warning: no patches were sent | error: last command exited with $?=1 | not ok 37 - reject long lines Remove the duplicate option specs. These are primarily the explicit '--no-' prefix opts which were added in f471494303 (git-send-email.perl: support no- prefix with older GetOptions, 2015-01-30). This was done specifically to support perl-5.8.0 which includes Getopt::Long 2.32[1]. Getopt::Long 2.33 added support for the '--no-' prefix natively by appending '!' to the option specification string, which was included in perl-5.8.1 and is not present in perl-5.8.0. The previous commit bumped the minimum supported Perl version to 5.8.1 so we no longer need to provide the '--no-' variants for negatable options manually. Teach `--git-completion-helper` to output the '--no-' options. They are not included in the options hash and would otherwise be lost. Signed-off-by: Todd Zullinger Signed-off-by: Junio C Hamano

perl: bump the required Perl version to 5.8.1 from 5.8.0

2023-11-16T22:26:32Z

The following commit will make use of a Getopt::Long feature which is only present in Perl >= 5.8.1. Document that as the minimum version we support. Many of our Perl scripts will continue to run with 5.8.0 but this change allows us to adjust them as needed without breaking any promises to our users. The Perl requirement was last changed in d48b284183 (perl: bump the required Perl version to 5.8 from 5.6.[21], 2010-09-24). At that time, 5.8.0 was 8 years old. It is now over 21 years old. Signed-off-by: Todd Zullinger Signed-off-by: Junio C Hamano

send-email: remove stray characters from usage

2023-11-16T05:00:34Z

A few stray single quotes crept into the usage string in a2ce608244 (send-email docs: add format-patch options, 2021-10-25). Remove them. Signed-off-by: Todd Zullinger Signed-off-by: Junio C Hamano

Merge branch 'ms/send-email-validate-fix'

2023-11-07T01:26:44Z

"git send-email" did not have certain pieces of data computed yet when it tried to validate the outging messages and its recipient addresses, which has been sorted out. * ms/send-email-validate-fix: send-email: move validation code below process_address_list

Merge branch 'jk/send-email-fix-addresses-from-composed-messages'

2023-10-29T22:09:59Z

The codepath to handle recipient addresses `git send-email --compose` learns from the user was completely broken, which has been corrected. * jk/send-email-fix-addresses-from-composed-messages: send-email: handle to/cc/bcc from --compose message Revert "send-email: extract email-parsing code into a subroutine" doc/send-email: mention handling of "reply-to" with --compose

send-email: move validation code below process_address_list

2023-10-26T12:46:10Z

Move validation logic below processing of email address lists so that email validation gets the proper email addresses. As a side effect, some initialization needed to be moved down. In order for validation and the actual email sending to have the same initial state, the initialized variables that get modified by pre_process_file are encapsulated in a new function. This fixes email address validation errors when the optional perl module Email::Valid is installed and multiple addresses are passed in on a single to/cc argument like --to=foo@example.com,bar@example.com. A new test was added to t9001 to expose failures with this case in the future. Reported-by: Bagas Sanjaya Signed-off-by: Michael Strawbridge Signed-off-by: Junio C Hamano

send-email: handle to/cc/bcc from --compose message

2023-10-20T21:31:39Z

If the user writes a message via --compose, send-email will pick up various headers like "From", "Subject", etc and use them for other patches as if they were specified on the command-line. But we don't handle "To", "Cc", or "Bcc" this way; we just tell the user "those aren't interpeted yet" and ignore them. But it seems like an obvious thing to want, especially as the same feature exists when the cover letter is generated separately by format-patch. There it is gated behind the --to-cover option, but I don't think we'd need the same control here; since we generate the --compose template ourselves based on the existing input, if the user leaves the lines unchanged then the behavior remains the same. So let's fill in the implementation; like those other headers we already handle, we just need to assign to the initial_* variables. The only difference in this case is that they are arrays, so we'll feed them through parse_address_line() to split them (just like we would when reading a single string via prompting). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Revert "send-email: extract email-parsing code into a subroutine"

2023-10-20T21:31:32Z

This reverts commit b6049542b97e7b135e0e82bf996084d461224d32. Prior to that commit, we read the results of the user editing the "--compose" message in a loop, picking out parts we cared about, and streaming the result out to a ".final" file. That commit split the reading/interpreting into two phases; we'd now read into a hash, and then pick things out of the hash. The goal was making the code more readable. And in some ways it did, because the ugly regexes are confined to the reading phase. But it also introduced several bugs, because now the two phases need to match each other. In particular: - we pick out headers like "Subject: foo" with a case-insensitive regex, and then use the user-provided header name as the key in a case-sensitive hash. So if the user wrote "subject: foo", we'd no longer recognize it as a subject. - the namespace for the hash keys conflates header names with meta information like "body". If you put "body: foo" in your message, it would be misinterpreted as the actual message body (nobody is likely to do that in practice, but it seems like an unnecessary danger). - the handling for to/cc/bcc is totally broken. The behavior before that commit is to recognize and skip those headers, with a note to the user that they are not yet handled. Not great, but OK. But after the patch, the reading side now splits the addresses into a perl array-ref. But the interpreting side doesn't handle this at all, and blindly prints the stringified array-ref value. This leads to garbage like: (mbox) Adding to: ARRAY (0x555b4345c428) from line 'To: ARRAY(0x555b4345c428)' error: unable to extract a valid address from: ARRAY (0x555b4345c428) What to do with this address? ([q]uit|[d]rop|[e]dit): Probably not a huge deal, since nobody should even try to use those headers in the first place (since they were not implemented). But the new behavior is worse, and indicative of the sorts of problems that come from having the two layers. The revert had a few conflicts, due to later work in this area from 15dc3b9161 (send-email: rename variable for clarity, 2018-03-04) and d11c943c78 (send-email: support separate Reply-To address, 2018-03-04). I've ported the changes from those commits over as part of the conflict resolution. The new tests show the bugs. Note the use of GIT_SEND_EMAIL_NOTTY in the second one. Without it, the test is happy to reach outside the test harness to the developer's actual terminal (when run with the buggy state before this patch). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano