summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2020-07-23git-send-email: die if sendmail.* config is setLibravatar Drew DeVault1-0/+8
I've seen several people mis-configure git send-email on their first attempt because they set the sendmail.* config options - not sendemail.*. This patch detects this mistake and bails out with a friendly warning. Signed-off-by: Drew DeVault <sir@cmpwn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-01send-email: restore --in-reply-to superseding behaviorLibravatar Rafael Aquini1-2/+6
git send-email --in-reply-to= fails to override In-Reply-To email headers, if they're present in the output of format-patch, even when explicitly told to do so by the option --no-thread, which breaks the contract of the command line switch option, per its man page. " --in-reply-to=<identifier> Make the first mail (or all the mails with --no-thread) appear as a reply to the given Message-Id, which avoids breaking threads to provide a new patch series. " This patch fixes the aformentioned issue, by bringing --in-reply-to's old overriding behavior back. The test was donated by Carlo Marcelo Arenas Belón. Signed-off-by: Rafael Aquini <aquini@redhat.com> Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in code commentsLibravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13Merge branch 'ab/send-email-transferencoding-fix'Libravatar Junio C Hamano1-89/+116
Since "git send-email" learned to take 'auto' as the value for the transfer-encoding, it by mistake stopped honoring the values given to the configuration variables sendemail.transferencoding and/or sendemail.<ident>.transferencoding. This has been corrected to (finally) redoing the order of setting the default, reading the configuration and command line options. * ab/send-email-transferencoding-fix: send-email: fix regression in sendemail.identity parsing send-email: document --no-[to|cc|bcc] send-email: fix broken transferEncoding tests send-email: remove cargo-culted multi-patch pattern in tests send-email: do defaults -> config -> getopt in that order send-email: rename the @bcclist variable for consistency send-email: move the read_config() function above getopts
2019-05-29send-email: fix regression in sendemail.identity parsingLibravatar Ævar Arnfjörð Bjarmason1-19/+40
Fix a regression in my recent 3494dfd3ee ("send-email: do defaults -> config -> getopt in that order", 2019-05-09). I missed that the $identity variable needs to be extracted from the command-line before we do the config reading, as it determines which config variable we should read first. See [1] for the report. The sendemail.identity feature was added back in 34cc60ce2b ("send-email: Add support for SSL and SMTP-AUTH", 2007-09-03), there were no tests to assert that it worked properly. So let's fix both the regression, and add some tests to assert that this is being parsed properly. While I'm at it I'm adding a --no-identity option to go with --[to|cc|bcc] variable, since the semantics are similar. It's like to/cc/bcc except that unlike those we don't support multiple identities, but we could now easily add it support for it if anyone cares. In just fixing the --identity command-line parsing bug I discovered that a narrow fix to that wouldn't do. In read_config() we had a state machine that would only set config values if they weren't set already, and thus by proxy we wouldn't e.g. set "to" based on sendemail.to if we'd seen sendemail.gmail.to before, with --identity=gmail. I'd modified some of the relevant code in 3494dfd3ee, but just reverting to that wouldn't do, since it would bring back the regression fixed in that commit. Refactor read_config() do what we actually mean here. We don't want to set a given sendemail.VAR if a sendemail.$identity.VAR previously set it. The old code was conflating this desire with the hardcoded defaults for these variables, and as discussed in 3494dfd3ee that was never going to work. Instead pass along the state of whether an identity config set something before, as distinguished from the state of the default just being false, or the default being a non-bool or true (e.g. --transferencoding). I'm still not happy with the test coverage here, e.g. there's nothing testing sendemail.smtpEncryption, but I only have so much time to fix this code. 1. https://public-inbox.org/git/5cddeb61.1c69fb81.47ed4.e648@mx.google.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13send-email: do defaults -> config -> getopt in that orderLibravatar Ævar Arnfjörð Bjarmason1-42/+49
Change the git-send-email command-line argument parsing and config reading code to parse those two in the right order. I.e. first we set our hardcoded defaults, then we read our config, and finally we read the command-line, with later sets overriding earlier sets. This fixes a bug introduced in e67a228cd8 ("send-email: automatically determine transfer-encoding", 2018-07-08). That change broke the reading of sendmail.transferencoding because it wasn't careful to update the code to parse them in the previous "defaults -> getopt -> config" order. But as we can see from the history for this file doing it this way was never what we actually wanted, it's just something we grew organically as of 5483c71d7a ("git-send-email: make options easier to configure.", 2007-06-27) and have been dealing with the fallout since, e.g. in 463b0ea22b ("send-email: Fix %config_path_settings handling", 2011-10-14). As can be seen in this change the only place where we actually want to do something clever is with the to/cc/bcc variables, where setting them on the command-line (or using --no-{to,cc,bcc}) should clear out values we grab from the config. All the rest are things where the command-line should simply override the config values, and by reading the config first the config code doesn't need all this "let's not set it, if it was on the command-line" special-casing, as [1] shows we'd otherwise need to care about the difference between whether something was a default or present in config to fix the bug in e67a228cd8. 1. https://public-inbox.org/git/20190508105607.178244-2-gitster@pobox.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13send-email: rename the @bcclist variable for consistencyLibravatar Ævar Arnfjörð Bjarmason1-5/+5
The "to" and "cc" variables are named @initial_{to,cc}, let's rename this one to match them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13send-email: move the read_config() function above getoptsLibravatar Ævar Arnfjörð Bjarmason1-49/+48
This is in preparation for a later change where we'll read the config first before parsing command-line options. As the move detection will show no lines (except one line of comment) is changed here, just moved around. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25Merge branch 'bs/sendemail-tighten-anything-by'Libravatar Junio C Hamano1-1/+1
The recently added feature to add addresses that are on anything-by: trailers in 'git send-email' was found to be way too eager and considered nonsense strings as if they can be legitimate beginning of *-by: trailer. This has been tightened. * bs/sendemail-tighten-anything-by: send-email: don't cc *-by lines with '-' prefix
2019-04-25Merge branch 'bc/send-email-qp-cr'Libravatar Junio C Hamano1-1/+1
"git send-email" has been taught to use quoted-printable when the payload contains carriage-return. The use of the mechanism is in line with the design originally added the codepath that chooses QP when the payload has overly long lines. * bc/send-email-qp-cr: send-email: default to quoted-printable when CR is present
2019-04-14send-email: default to quoted-printable when CR is presentLibravatar brian m. carlson1-1/+1
In 7a36987fff ("send-email: add an auto option for transfer encoding", 2018-07-08), git send-email learned how to automatically determine the transfer encoding for a patch. However, the only criterion considered was the length of the lines. Another case we need to consider is that of carriage returns. Because emails have CRLF endings when canonicalized, we don't want to write raw carriage returns into a patch, lest they be stripped off as an artifact of the transport. Ensure that we choose quoted-printable encoding if the patch we're sending contains carriage returns. Note that we are guaranteed to always correctly encode carriage returns when writing quoted-printable since we explicitly specify the line ending as "\n", forcing MIME::QuotedPrint to encode our carriage return as "=0D". Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-04send-email: don't cc *-by lines with '-' prefixLibravatar Baruch Siach1-1/+1
Since commit ef0cc1df90f6b ("send-email: also pick up cc addresses from -by trailers") in git version 2.20, git send-email adds to cc list addresses from all *-by lines. As a side effect a line with '-Signed-off-by' is now also added to cc. This makes send-email pick lines from patches that remove patch files from the git repo. This is common in the Buildroot project that often removes (and adds) patch files that have 'Signed-off-by' in their patch description part. Consider only *-by lines that start with [a-z] (case insensitive) to avoid unrelated addresses in cc. Cc: Joe Perches <joe@perches.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-20completion: add more parameter value completionLibravatar Nguyễn Thái Ngọc Duy1-0/+6
This adds value completion for a couple more paramters. To make it easier to maintain these hard coded lists, add a comment at the original list/code to remind people to update git-completion.bash too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'nd/complete-format-patch'Libravatar Junio C Hamano1-0/+8
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
2018-11-13Merge branch 'al/send-email-auto-cte-fixup'Libravatar Junio C Hamano1-1/+1
"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
2018-11-06Merge branch 'jw/send-email-no-auth'Libravatar Junio C Hamano1-2/+6
"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
2018-11-06completion: use __gitcomp_builtin for format-patchLibravatar Duy Nguyen1-0/+8
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 <liu.denton@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02send-email: avoid empty transfer encoding headerLibravatar Aaron Lindsay1-1/+1
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 <aaron@aclindsay.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23send-email: explicitly disable authenticationLibravatar Joshua Watt1-2/+6
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 <JPEWhacker@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16send-email: also pick up cc addresses from -by trailersLibravatar Rasmus Villemoes1-7/+12
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 <joe@perches.com> Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11send-email: only consider lines containing @ or <> for automatic Cc'ingLibravatar Rasmus Villemoes1-0/+5
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 <user at domain.com> (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 <user at domain.com> 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 <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'jm/send-email-tls-auth-on-batch'Libravatar Junio C Hamano1-2/+1
"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
2018-07-16send-email: fix tls AUTH when sending batchLibravatar Jules Maselbas1-2/+1
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 <jules.maselbas@grenoble-inp.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: automatically determine transfer-encodingLibravatar brian m. carlson1-12/+6
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: accept long lines with suitable transfer encodingLibravatar brian m. carlson1-7/+11
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: add an auto option for transfer encodingLibravatar brian m. carlson1-5/+7
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-30Merge branch 'dd/send-email-reedit'Libravatar Junio C Hamano1-7/+31
"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
2018-05-06git-send-email: allow re-editing of messageLibravatar Drew DeVault1-7/+31
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 <sir@cmpwn.com> Reviewed-by: Simon Ser <contact@emersion.fr> Helped-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-19send-email: avoid duplicate In-Reply-To/ReferencesLibravatar Stefan Agner1-1/+6
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 <stefan@agner.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15Merge branch 'ab/perl-fixes'Libravatar Junio C Hamano1-15/+13
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
2018-03-15Merge branch 'cl/send-email-reply-to'Libravatar Junio C Hamano1-19/+35
"git send-email" learned "--reply-to=<address>" option. * cl/send-email-reply-to: send-email: support separate Reply-To address send-email: rename variable for clarity
2018-03-15Merge branch 'np/send-email-header-parsing'Libravatar Junio C Hamano1-38/+77
Code refactoring. * np/send-email-header-parsing: send-email: extract email-parsing code into a subroutine
2018-03-06Merge branch 'xz/send-email-batch-size'Libravatar Junio C Hamano1-0/+4
"git send-email" learned to complain when the batch-size option is not defined when the relogin-delay option is, since these two are mutually required. * xz/send-email-batch-size: send-email: error out when relogin delay is missing
2018-03-06send-email: support separate Reply-To addressLibravatar Christian Ludwig1-1/+17
In some projects contributions from groups are only accepted from a common group email address. But every individual may want to receive replies to her own personal address. That's what we have 'Reply-To' headers for in SMTP. So introduce an optional '--reply-to' command line option. This patch re-uses the $reply_to variable. This could break out-of-tree patches! Signed-off-by: Christian Ludwig <chrissicool@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-06send-email: rename variable for clarityLibravatar Christian Ludwig1-19/+19
The SMTP protocol has both, the 'Reply-To' and the 'In-Reply-To' header fields. We only use the latter. To avoid confusion, rename the variable for it. Signed-off-by: Christian Ludwig <chrissicool@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05perl: move CPAN loader wrappers to another namespaceLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Move the Git::Error and Git::Mail::Address wrappers to the Git::LoadCPAN::Loader::* namespace, e.g. Git::LoadCPAN::Error. That module will then either load Error from CPAN (if installed on the OS), or use Git::FromCPAN::Error. When I added the Error wrapper in 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) I didn't think about how confusing it would be to have these modules sitting in the same tree as our normal modules. Let's put these all into Git::{Load,From}CPAN::* to clearly distinguish them from the rest. This also makes things a bit less confusing since there was already a Git::Error namespace ever since 8b9150e3e3 ("Git.pm: Handle failed commands' output", 2006-06-24). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-05git-send-email: unconditionally use Net::{SMTP,Domain}Libravatar Ævar Arnfjörð Bjarmason1-13/+11
The Net::SMTP and Net::Domain were both first released with perl v5.7.3[1], since my d48b284183 ("perl: bump the required Perl version to 5.8 from 5.6.[21]", 2010-09-24) we've depended on 5.8, so there's no reason to conditionally require them anymore. This conditional loading was initially added in 87840620fd ("send-email: only 'require' instead of 'use' Net::SMTP", 2006-06-01) for Net::SMTP and 134550fe21 ("git-send-email.perl - try to give real name of the calling host to HELO/EHLO", 2010-03-14) for Net::Domain, both of which predate the hard dependency on 5.8. Since they're guaranteed to be installed now let's "use" them instead. The cost of loading them both is trivial given what git-send-email does (~15ms on my system), and it's better to not defer any potential loading errors until runtime. This patch is better viewed with -w, which shows that the only change in the last two hunks is removing the "if eval" wrapper block. 1. $ parallel 'corelist {}' ::: Net::{SMTP,Domain} Data for 2015-02-14 Net::SMTP was first released with perl v5.7.3 Data for 2015-02-14 Net::Domain was first released with perl v5.7.3 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-13Merge branch 'ab/simplify-perl-makefile'Libravatar Junio C Hamano1-1/+1
The build procedure for perl/ part has been greatly simplified by weaning ourselves off of MakeMaker. * ab/simplify-perl-makefile: perl: treat PERLLIB_EXTRA as an extra path again perl: avoid *.pmc and fix Error.pm further Makefile: replace perl/Makefile.PL with simple make rules
2018-02-12send-email: error out when relogin delay is missingLibravatar Stefan Beller1-0/+4
When the batch size is neither configured nor given on the command line, but the relogin delay is given, then the current code ignores the relogin delay setting. This is unsafe as there was some intention when setting the batch size. One workaround would be to just assume a batch size of 1 as a default. This however may be bad UX, as then the user may wonder why it is sending slowly without apparent batching. Error out for now instead of potentially confusing the user. As 5453b83bdf (send-email: --batch-size to work around some SMTP server limit, 2017-05-21) lays out, we rather want to not have this interface anyway and would rather want to react on the server throttling dynamically. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05send-email: add and use a local copy of Mail::AddressLibravatar Matthieu Moy1-1/+2
We used to have two versions of the email parsing code. Our parse_mailboxes (in Git.pm), and Mail::Address which we used if installed. Unfortunately, both versions have different sets of bugs, and changing the behavior of git depending on whether Mail::Address is installed was a bad idea. A first attempt to solve this was cc90750 (send-email: don't use Mail::Address, even if available, 2017-08-23), but it turns out our parse_mailboxes is too buggy for some uses. For example the lack of nested comments support breaks get_maintainer.pl in the Linux kernel tree: https://public-inbox.org/git/20171116154814.23785-1-alex.bennee@linaro.org/ This patch goes the other way: use Mail::Address anyway, but have a local copy from CPAN as a fallback, when the system one is not available. The duplicated script is small (276 lines of code) and stable in time. Maintaining the local copy should not be an issue, and will certainly be less burden than maintaining our own parse_mailboxes. Another option would be to consider Mail::Address as a hard dependency, but it's easy enough to save the trouble of extra-dependency to the end user or packager. Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-15send-email: extract email-parsing code into a subroutineLibravatar Nathan Payre1-38/+77
The existing code mixes parsing of email header with regular expression and actual code. Extract the parsing code into a new subroutine "parse_header_line()". This improves the code readability and make parse_header_line reusable in other place. "parsed_header_line()" and "filter_body()" could be used for refactoring the part of code which parses the header to prepare the email and send it. In contrast to the previous version it doesn't keep the header order and strip duplicate headers. Signed-off-by: Nathan Payre <nathan.payre@etu.univ-lyon1.fr> Signed-off-by: Matthieu Moy <matthieu.moy@univ-lyon1.fr> Signed-off-by: Timothee Albertin <timothee.albertin@etu.univ-lyon1.fr> Signed-off-by: Daniel Bensoussan <daniel.bensoussan--bohm@etu.univ-lyon1.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Matthieu Moy <matthieu.moy@univ-lyon1.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11Makefile: replace perl/Makefile.PL with simple make rulesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Replace the perl/Makefile.PL and the fallback perl/Makefile used under NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily inspired by how the i18n infrastructure's build process works[1]. The reason for having the Makefile.PL in the first place is that it was initially[2] building a perl C binding to interface with libgit, this functionality, that was removed[3] before Git.pm ever made it to the master branch. We've since since started maintaining a fallback perl/Makefile, as MakeMaker wouldn't work on some platforms[4]. That's just the tip of the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to detect whether we need to regenerate the perl/perl.mak, which I fixed just recently to deal with issues like the perl version changing from under us[6]. There is absolutely no reason for why this needs to be so complex anymore. All we're getting out of this elaborate Rube Goldberg machine was copying perl/* to perl/blib/* as we do a string-replacement on the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as pod2man-ing Git.pm & friends. So replace the whole thing with something that's pretty much a copy of how we generate po/build/**.mo from po/*.po, just with a small sed(1) command instead of msgfmt. As that's being done rename the files from *.pm to *.pmc just to indicate that they're generated (see "perldoc -f require"). While I'm at it, change the fallback for Error.pm from being something where we'll ship our own Error.pm if one doesn't exist at build time to one where we just use a Git::Error wrapper that'll always prefer the system-wide Error.pm, only falling back to our own copy if it really doesn't exist at runtime. It's now shipped as Git::FromCPAN::Error, making it easy to add other modules to Git::FromCPAN::* in the future if that's needed. Functional changes: * This will not always install into perl's idea of its global "installsitelib". This only potentially matters for packagers that need to expose Git.pm for non-git use, and as explained in the INSTALL file there's a trivial workaround. * The scripts themselves will 'use lib' the target directory, but if INSTLIBDIR is set it overrides it. It doesn't have to be this way, it could be set in addition to INSTLIBDIR, but my reading of [7] is that this is the desired behavior. * We don't build man pages for all of the perl modules as we used to, only Git(3pm). As discussed on-list[8] that we were building installed manpages for purely internal APIs like Git::I18N or private-Error.pm was always a bug anyway, and all the Git::SVN::* ones say they're internal APIs. There are apparently external users of Git.pm, but I don't expect there to be any of the others. As a side-effect of these general changes the perl documentation now only installed by install-{doc,man}, not a mere "install" as before. 1. 5e9637c629 ("i18n: add infrastructure for translating Git with gettext", 2011-11-18) 2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24) 3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23) 4. f848718a69 ("Make perl/ build procedure ActiveState friendly.", 2006-12-04) 5. ee9be06770 ("perl: detect new files in MakeMaker builds", 2012-07-27) 6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes", 2017-03-29) 7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to default perl path", 2013-11-15) 8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules" Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-28git-send-email: honor $PATH for sendmail binaryLibravatar Florian Klink1-1/+3
This extends git-send-email to also consider sendmail binaries in $PATH after checking the (fixed) list of /usr/sbin and /usr/lib, and before falling back to localhost. Signed-off-by: Florian Klink <flokli@flokli.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24send-email: don't use Mail::Address, even if availableLibravatar Matthieu Moy1-6/+1
Using Mail::Address made sense when we didn't have a proper parser. We now have a reasonable address parser, and using Mail::Address _if available_ causes much more trouble than it gives benefits: * Developers typically test one version, not both. * Users may not be aware that installing Mail::Address will change the behavior. They may complain about the behavior in one case without knowing that Mail::Address is involved. * Having this optional Mail::Address makes it tempting to anwser "please install Mail::Address" to users instead of fixing our own code. We've reached the stage where bugs in our parser should be fixed, not worked around. Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24send-email: fix garbage removal after addressLibravatar Matthieu Moy1-2/+24
This is a followup over 9d33439 (send-email: only allow one address per body tag, 2017-02-20). The first iteration did allow writting Cc: <foo@example.com> # garbage but did so by matching the regex ([^>]*>?), i.e. stop after the first instance of '>'. However, it did not properly deal with Cc: foo@example.com # garbage Fix this using a new function strip_garbage_one_address, which does essentially what the old ([^>]*>?) was doing, but dealing with more corner-cases. Since we've allowed Cc: "Foo # Bar" <foobar@example.com> in previous versions, it makes sense to continue allowing it (but we still remove any garbage after it). OTOH, when an address is given without quoting, we just take the first word and ignore everything after. Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-06Merge branch 'xz/send-email-batch-size'Libravatar Junio C Hamano1-0/+18
"git send-email" learned to overcome some SMTP server limitation that does not allow many pieces of e-mails to be sent over a single session. * xz/send-email-batch-size: send-email: --batch-size to work around some SMTP server limit
2017-07-05send-email: --batch-size to work around some SMTP server limitLibravatar xiaoqiang zhao1-0/+18
Some email servers (e.g. smtp.163.com) limit the number emails to be sent per session (connection) and this will lead to a faliure when sending many messages. Teach send-email to disconnect after sending a number of messages (configurable via the --batch-size=<num> option), wait for a few seconds (configurable via the --relogin-delay=<seconds> option) and reconnect, to work around such a limit. Also add two configuration variables to give these options the default. Note: We will use this as a band-aid for now, but in the longer term, we should look at and react to the SMTP error code from the server; Xianqiang reports that 450 and 451 are returned by problematic servers. cf. https://public-inbox.org/git/7993e188.d18d.15c3560bcaf.Coremail.zxq_yx_007@163.com/ Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02Merge branch 'jt/send-email-validate-hook'Libravatar Junio C Hamano1-15/+17
A hotfix for a topic already in 'master'. * jt/send-email-validate-hook: send-email: check for repo before invoking hook
2017-06-02Merge branch 'dk/send-email-avoid-net-smtp-ssl-when-able'Libravatar Junio C Hamano1-1/+1
A hotfix to a topic in 'master'. * dk/send-email-avoid-net-smtp-ssl-when-able: send-email: Net::SMTP::starttls was introduced in v2.34
2017-06-02send-email: check for repo before invoking hookLibravatar Jonathan Tan1-15/+17
Unless --no-validate is passed, send-email will invoke $repo->repo_path() in its search for a validate hook regardless of whether a Git repo is actually present. Teach send-email to first check for repo existence. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>