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

Merge branch 'nd/complete-format-patch'

2018-11-13T13:37:28Z

The support for format-patch (and send-email) by the command-line completion script (in contrib/) has been simplified a bit. * nd/complete-format-patch: completion: use __gitcomp_builtin for format-patch

Merge branch 'al/send-email-auto-cte-fixup'

2018-11-13T13:37:25Z

"git send-email --transfer-encoding=..." in recent versions of Git sometimes produced an empty "Content-Transfer-Encoding:" header, which has been corrected. * al/send-email-auto-cte-fixup: send-email: avoid empty transfer encoding header

Merge branch 'jw/send-email-no-auth'

2018-11-06T06:50:20Z

"git send-email" learned to disable SMTP authentication via the "--smtp-auth=none" option, even when the smtp username is given (which turns the authentication on by default). * jw/send-email-no-auth: send-email: explicitly disable authentication

completion: use __gitcomp_builtin for format-patch

2018-11-06T04:22:30Z

This helps format-patch gain completion for a couple new options, notably --range-diff. Since send-email completion relies on $__git_format_patch_options which is now reduced, we need to do something not to regress send-email completion. The workaround here is implement --git-completion-helper in send-email.perl just as a bridge to "format-patch --git-completion-helper". This is enough to use __gitcomp_builtin on send-email (to take advantage of caching). In the end, send-email.perl can probably reuse the same info it passes to GetOptions() to generate full --git-completion-helper output so that we don't need to keep track of its options in git-completion.bash anymore. But that's something for another boring day. Helped-by: Denton Liu Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

send-email: avoid empty transfer encoding header

2018-11-02T14:59:53Z

Fix a small bug introduced by "7a36987ff (send-email: add an auto option for transfer encoding, 2018-07-14)". I saw the following message when setting --transfer-encoding for a file with the same encoding: $ git send-email --transfer-encoding=8bit example.patch Use of uninitialized value $xfer_encoding in concatenation (.) or string at /usr/lib/git-core/git-send-email line 1744. The new tests are by brian m. carlson. Signed-off-by: Aaron Lindsay Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

send-email: explicitly disable authentication

2018-10-23T04:37:14Z

It can be necessary to disable SMTP authentication by a mechanism other than sendemail.smtpuser being undefined. For example, if the user has sendemail.smtpuser set globally but wants to disable authentication locally in one repository. --smtp-auth and sendemail.smtpauth now understand the value 'none' which means to disable authentication completely, even if an authentication user is specified. The value 'none' is lower case to avoid conflicts with any RFC 4422 authentication mechanisms. The user may also specify the command line argument --no-smtp-auth as a shorthand for --smtp-auth=none Signed-off-by: Joshua Watt Signed-off-by: Junio C Hamano

send-email: also pick up cc addresses from -by trailers

2018-10-16T07:55:14Z

When rerolling a patch series, including various Reviewed-by etc. that may have come in, it is quite convenient to have git-send-email automatically cc those people. So pick up any *-by lines, with a new suppression category 'misc-by', but special-case Signed-off-by, since that already has its own suppression category. It seems natural to make 'misc-by' implied by 'body'. Based-on-patch-by: Joe Perches Signed-off-by: Rasmus Villemoes Signed-off-by: Junio C Hamano

send-email: only consider lines containing @ or <> for automatic Cc'ing

2018-10-11T06:19:33Z

While the address sanitizations routines do accept local addresses, that is almost never what is meant in a Cc or Signed-off-by trailer. Looking through all the signed-off-by lines in the linux kernel tree without a @, there are mostly two patterns: Either just a full name, or a full name followed by (i.e., with the word at instead of a @), and minor variations. For cc lines, the same patterns appear, along with lots of "cc stable" variations that do not actually name stable@vger.kernel.org Cc: stable # introduced pre-git times cc: stable.kernel.org In the cases, one gets a chance to interactively fix it. But when there is no <> pair, it seems we end up just using the first word as a (local) address. As the number of cases where a local address really was meant is likely (and anecdotally) quite small compared to the number of cases where we end up cc'ing a garbage address, insist on at least a @ or a <> pair being present. This is also preparation for the next patch, where we are likely to encounter even more non-addresses in -by lines, such as Reported-by: Coverity Patch-generated-by: Coccinelle Signed-off-by: Rasmus Villemoes Signed-off-by: Junio C Hamano

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