git/git-send-email.perl, branch jch

Merge branch 'sp/send-email-validate-charset'

2026-03-12T17:56:05Z

"git send-email" has learned to be a bit more careful when it accepts charset to use from the end-user, to avoid 'y' (mistaken 'yes' when expecting a charset like 'UTF-8') and other nonsense. * sp/send-email-validate-charset: send-email: validate charset name in 8bit encoding prompt

Merge branch 'dt/send-email-client-cert'

2026-03-12T17:56:05Z

"git send-email" learns to support use of client-side certificates. * dt/send-email-client-cert: send-email: add client certificate options

send-email: pass smtp hostname and port to Authen::SASL

2026-03-05T19:28:45Z

Starting from version 2.2000, Authen::SASL supports passing the SMTP server hostname and port to the OAUTHBEARER string passed via SMTP AUTH. Add support for the same in git-send-email. It's safe to add the new parameters unconditionally as older versions of Authen::SASL will simply ignore them without any error. Something similar is already being done for the authname parameter, which is not supported by every authentication mechanism. This can be understood as declaring a variable but not using at all. Link: https://metacpan.org/pod/Authen::SASL::Perl::OAUTHBEARER Signed-off-by: Aditya Garg Signed-off-by: Junio C Hamano

send-email: add client certificate options

2026-03-02T16:39:26Z

For SMTP servers that do "mutual certificate verification", the mail client is required to present its own TLS certificate as well. This patch adds --smtp-ssl-client-cert and --smtp-ssl-client-key for such servers. The problem of which private key for the certificate is chosen arises when there are private keys in both the certificate and private key file. According to the documentation of IO::Socket::SSL(link supplied), the behaviour(the private key chosen) depends on the format of the certificate. In a nutshell, - PKCS12: the key in the cert always takes the precedence - PEM: if the key file is not given, it will "try" to read one from the cert PEM file Many users may find this discrepancy unintuitive. In terms of client certificate, git-send-email is implemented in a way that what's possible with perl's SSL library is exposed to the user as much as possible. In this instance, the user may choose to use a PEM file that contains both certificate and private key should be at their discretion despite the implications. Link: https://metacpan.org/pod/IO::Socket::SSL#SSL_cert_file-%7C-SSL_cert-%7C-SSL_key_file-%7C-SSL_key Link: https://lore.kernel.org/all/319bf98c-52df-4bf9-b157-e4bc2bf087d6@dev.snart.me/ Signed-off-by: David Timber Signed-off-by: Junio C Hamano

send-email: validate charset name in 8bit encoding prompt

2026-03-02T16:09:16Z

When a non-ASCII character is detected in the body or subject of the email the user is prompted with, Which 8bit encoding should I declare [UTF-8]? foo After this the input string is validated by the regex, based on the fact that the charset string will be minimum 4 characters [1]. If the string is more than 4 letters the email is sent, if not then a second prompt to confirm is asked to the user, Are you sure you want to use [y/N]? y This relies on a length based regex heuristic check to validate the user input, and can allow clearly invalid charset names to pass if the input is greater than 4 characters. Add a semantic validation of the charset name using the Encode::find_encoding() which is a bundled module of perl. If the encoding is not recognized, warn the user and ask for confirmation before proceeding. After this validation the lenght based validation becomes redundant and also breaks flow, so change the regex of valid input to any non blank string. Make the encoding warning logic specific to the 8bit prompt, also add a unique confirmation prompt which reduces the load on ask(), and improves maintainability. Additionally, the wording of the first prompt can confuse the user if not read properly or under any default assumptions for a yes/no prompt. Change the wording to make it explicitly clear to the user that the prompt needs a string input, UTF-8 being the default. The intended flow is, Declare which 8bit encoding to use [default: UTF-8]? foobar 'foobar' does not appear to be a valid charset name. Use it anyway [y/N]? [1]- https://github.com/git/git/commit/852a15d748034eec87adbee73a72689c8936fb8b Signed-off-by: Shreyansh Paliwal Signed-off-by: Junio C Hamano

Merge branch 'nb/send-email-no-dup-reply-to'

2025-09-29T18:40:33Z

"git send-email --compose --reply-to=

" used to add duplicated Reply-To: header, which made mailservers unhappy. This has been corrected. * nb/send-email-no-dup-reply-to: send-email: don't duplicate Reply-to: in intro message

send-email: don't duplicate Reply-to: in intro message

2025-09-17T14:05:46Z

If I run git send-email --compose --reply-to 'ME ' ..... and edit the intro message, then it will get two copies of the Reply-To field. gmail.com rejects such messages. This happens because send-email reads the edited message examining the headers. For recognised headers the content is extracted to use in constructing the final message and for possible inclusion in the patch emails. Unrecognised headers are gathered (in @xh) to be passed through uninterpreted. Unfortunately "Reply-To" is not recognised in this process so it is added to @xh as an uninterpreted header, but also generated from the $reply_to variable in gen_header(), resulting in two copies Add parsing to the loop in pre_process_file() to recognise a Reply-to header and to store the result in $reply_to. This means that the intro message will not get a second header and also means that any changes made to the Reply-To header during editing will be incorporated in the $reply_to variable and so included in all the generated email messages. Signed-off-by: NeilBrown Signed-off-by: Junio C Hamano

send-email: enable copying emails to an IMAP folder without actually sending them

2025-08-12T15:59:36Z

`git imap-send` was built on the idea of copying emails to an IMAP folder like drafts, and sending them later using an email client. Currently the only way to do it is by piping output of `git format-patch` to IMAP send. Add another way to do it by using `git send-email` with the `--use-imap-only` or `sendmail.useImapOnly` option. This allows users to use the advanced features of `git send-email` like tweaking Cc: list programmatically, compose the cover letter, etc. and then send the well formatted emails to an IMAP folder using `git imap-send`. While at it, use `` instead of '' for --smtp-encryption ssl in help section of `git send-email`. Signed-off-by: Aditya Garg Signed-off-by: Junio C Hamano

send-email: add ability to send a copy of sent emails to an IMAP folder

2025-08-12T15:59:35Z

Some email providers like Apple iCloud Mail do not support sending a copy of sent emails to the "Sent" folder if SMTP server is used. As a workaround, various email clients like Thunderbird which rely on SMTP, use IMAP to send a copy of sent emails to the "Sent" folder. Something similar can be done if sending emails via `git send-email`, by using the `git imap-send` command to send a copy of the sent email to an IMAP folder specified by the user. Add this functionality to `git send-email` by introducing a new configuration variable `sendemail.imapfolder` and command line option `--imap-folder` which specifies the IMAP folder to send a copy of the sent emails to. If specified, a copy of the sent emails will be sent by piping the emails to `git imap-send` command, after all emails are sent via SMTP and the SMTP server has been closed. Signed-off-by: Aditya Garg Signed-off-by: Junio C Hamano

Merge branch 'mc/netrc-service-names'

2025-07-14T18:19:25Z

"netrc" credential helper has been improved to understand textual service names (like smtp) in addition to the numeric port numbers (like 25). * mc/netrc-service-names: contrib: better support symbolic port names in git-credential-netrc contrib: warn for invalid netrc file ports in git-credential-netrc contrib: use a more portable shebang for git-credential-netrc