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

Merge branch 'jm/send-email-tls-auth-on-batch'

2018-08-02T22:30:46Z

"git send-email" when using in a batched mode that limits the number of messages sent in a single SMTP session lost the contents of the variable used to choose between tls/ssl, unable to send the second and later batches, which has been fixed. * jm/send-email-tls-auth-on-batch: send-email: fix tls AUTH when sending batch

send-email: fix tls AUTH when sending batch

2018-07-16T22:02:36Z

The variable smtp_encryption must keep it's value between two batches. Otherwise the authentication is skipped after the first batch. Signed-off-by: Jules Maselbas Signed-off-by: Junio C Hamano

send-email: automatically determine transfer-encoding

2018-07-09T17:55:12Z

git send-email, when invoked without a --transfer-encoding option, sends 8bit data without a MIME version or a transfer encoding. This has several downsides. First, unless the transfer encoding is specified, it defaults to 7bit, meaning that non-ASCII data isn't allowed. Second, if lines longer than 998 bytes are used, we will send an message that is invalid according to RFC 5322. The --validate option, which is the default, catches this issue, but it isn't clear to many people how to resolve this. To solve these issues, default the transfer encoding to "auto", so that we explicitly specify 8bit encoding when lines don't exceed 998 bytes and quoted-printable otherwise. This means that we now always emit Content-Transfer-Encoding and MIME-Version headers, so remove the conditionals from this portion of the code. It is unlikely that the unconditional inclusion of these two headers will affect the deliverability of messages in anything but a positive way, since MIME is already widespread and well understood by most email programs. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

send-email: accept long lines with suitable transfer encoding

2018-07-09T17:55:12Z

With --validate (which is the default), we warn about lines exceeding 998 characters due to the limits specified in RFC 5322. However, if we're using a suitable transfer encoding (quoted-printable or base64), we're guaranteed not to have lines exceeding 76 characters, so there's no need to fail in this case. The auto transfer encoding handles this specific case, so accept it as well. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

send-email: add an auto option for transfer encoding

2018-07-09T17:55:12Z

For most patches, using a transfer encoding of 8bit provides good compatibility with most servers and makes it as easy as possible to view patches. However, there are some patches for which 8bit is not a valid encoding: RFC 5322 specifies that a message must not have lines exceeding 998 octets. Add a transfer encoding value, auto, which indicates that a patch should use 8bit where allowed and quoted-printable otherwise. Choose quoted-printable instead of base64, since base64-encoded plain text is treated as suspicious by some spam filters. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'dd/send-email-reedit'

2018-05-30T05:04:03Z

"git send-email" can sometimes offer confirmation dialog "Send this email?" with choices 'Yes', 'No', 'Quit', and 'All'. A new action 'Edit' has been added to this dialog's choice. * dd/send-email-reedit: git-send-email: allow re-editing of message

git-send-email: allow re-editing of message

2018-05-06T03:56:57Z

When shown the email summary, an opportunity is presented for the user to edit the email as if they had specified --annotate. This also permits them to edit it multiple times. Signed-off-by: Drew DeVault Reviewed-by: Simon Ser Helped-by: Eric Wong Signed-off-by: Junio C Hamano

send-email: avoid duplicate In-Reply-To/References

2018-04-18T22:04:29Z

In case a patch already has In-Reply-To or References in the header (e.g. when the patch has been created with format-patch --thread) git-send-email should not add another pair of those headers. This is also not allowed according to RFC 5322 Section 3.6: https://tools.ietf.org/html/rfc5322#section-3.6 Avoid the second pair by reading the current headers into the appropriate variables. Signed-off-by: Stefan Agner Signed-off-by: Junio C Hamano

Merge branch 'ab/perl-fixes'

2018-03-15T22:00:46Z

Clean-up to various pieces of Perl code we have. * ab/perl-fixes: perl Git::LoadCPAN: emit better errors under NO_PERL_CPAN_FALLBACKS Makefile: add NO_PERL_CPAN_FALLBACKS knob perl: move the perl/Git/FromCPAN tree to perl/FromCPAN perl: generalize the Git::LoadCPAN facility perl: move CPAN loader wrappers to another namespace perl: update our copy of Mail::Address perl: update our ancient copy of Error.pm git-send-email: unconditionally use Net::{SMTP,Domain} Git.pm: hard-depend on the File::{Temp,Spec} modules gitweb: hard-depend on the Digest::MD5 5.8 module Git.pm: add the "use warnings" pragma Git.pm: remove redundant "use strict" from sub-package perl: *.pm files should not have the executable bit

Merge branch 'cl/send-email-reply-to'

2018-03-15T22:00:45Z

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

" option. * cl/send-email-reply-to: send-email: support separate Reply-To address send-email: rename variable for clarity