summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)Author
2018-08-02Merge branch 'jm/send-email-tls-auth-on-batch'Junio C Hamano
"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 batchJules Maselbas
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-encodingbrian m. carlson
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 encodingbrian m. carlson
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 encodingbrian m. carlson
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'Junio C Hamano
"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 messageDrew DeVault
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-18send-email: avoid duplicate In-Reply-To/ReferencesStefan Agner
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'Junio C Hamano
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'Junio C Hamano
"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'Junio C Hamano
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'Junio C Hamano
"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 addressChristian Ludwig
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 clarityChristian Ludwig
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 namespaceÆvar Arnfjörð Bjarmason
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}Ævar Arnfjörð Bjarmason
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'Junio C Hamano
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 missingStefan Beller
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::AddressMatthieu Moy
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 subroutineNathan Payre
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 rulesÆvar Arnfjörð Bjarmason
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 binaryFlorian Klink
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 availableMatthieu Moy
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 addressMatthieu Moy
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-07Merge branch 'xz/send-email-batch-size'Junio C Hamano
"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 limitxiaoqiang zhao
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'Junio C Hamano
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'Junio C Hamano
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 hookJonathan Tan
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>
2017-06-01send-email: Net::SMTP::starttls was introduced in v2.34Jonathan Nieder
We cannot rely on the starttls method being present in Net::SMTP until c274b798e6881a941d941808c6d89966975cb8c8 (Merge branch 'ipv6_ssl' of https://github.com/noxxi/perl-libnet into noxxi-ipv6_ssl, 2014-06-02), which set the module version to 2.34. This version was first shipped as part of perl in v5.21.5~169 (Update libnet to CPAN version 3.01, 2014-10-10). Noticed on an Ubuntu system with perl 5.18.2-2ubuntu1.1, which provides Net::SMTP version 2.31. The error message is Can't locate object method "starttls" via package "Net::SMTP" at /usr/lib/git-core/git-send-email line 1410. Reported-by: Brandon Williams <bmwill@google.com> Reported-and-tested-by: Eric Biggers <ebiggers3@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-30Merge branch 'dk/send-email-avoid-net-smtp-ssl-when-able'Junio C Hamano
"git send-email" now uses Net::SMTP::SSL, which is obsolete, only when needed. Recent versions of Net::SMTP can do TLS natively. * dk/send-email-avoid-net-smtp-ssl-when-able: send-email: Net::SMTP::SSL is obsolete, use only when necessary
2017-05-20send-email: Net::SMTP::SSL is obsolete, use only when necessaryDennis Kaarsemaker
Net::SMTP itself can do the necessary SSL and STARTTLS bits just fine since version 1.28, and Net::SMTP::SSL is now deprecated. Since 1.28 isn't that old yet, keep the old code in place and use it when necessary. While we're in the area, mark some messages for translation that were not yet marked as such. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-16send-email: support validate hookJonathan Tan
Currently, send-email has support for rudimentary e-mail validation. Allow the user to add support for more validation by providing a sendemail-validate hook. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21Merge branch 'jh/send-email-one-cc' into maintJunio C Hamano
"Cc:" on the trailer part does not have to conform to RFC strictly, unlike in the e-mail header. "git send-email" has been updated to ignore anything after '>' when picking addresses, to allow non-address cruft like " # stable 4.4" after the address. * jh/send-email-one-cc: send-email: only allow one address per body tag
2017-03-10Merge branch 'jh/send-email-one-cc'Junio C Hamano
"Cc:" on the trailer part does not have to conform to RFC strictly, unlike in the e-mail header. "git send-email" has been updated to ignore anything after '>' when picking addresses, to allow non-address cruft like " # stable 4.4" after the address. * jh/send-email-one-cc: send-email: only allow one address per body tag
2017-02-27send-email: only allow one address per body tagJohan Hovold
Adding comments after a tag in the body is a common practise (e.g. in the Linux kernel) and git-send-email has been supporting this for years by removing any trailing cruft after the address. After some recent changes, any trailing comment is now instead appended to the recipient name (with some random white space inserted) resulting in undesirable noise in the headers, for example: CC: "# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org> Revert to the earlier behaviour of discarding anything after the (first) address in a tag while parsing the body. Note that multiple addresses after are still allowed after a command line switch (and in a CC header field). Also note that --suppress-cc=self was never honoured when using multiple addresses in a tag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark composing message for translationVasco Almeida
When composing an e-mail, there is a message for the user whose lines begin in "GIT:" that can be marked for translation. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark string with interpolation for translationVasco Almeida
Mark warnings, errors and other messages that are interpolated for translation. We call sprintf() before calling die() and in few other circumstances in order to replace the values on the placeholders. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark warnings and errors for translationVasco Almeida
Mark warnings, errors and other messages for translation. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark strings for translationVasco Almeida
Mark strings often displayed to the user for translation. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11Merge branch 'jc/send-email-skip-backup'Junio C Hamano
A careless invocation of "git send-email directory/" after editing 0001-change.patch with an editor often ends up sending both 0001-change.patch and its backup file, 0001-change.patch~, causing embarrassment and a minor confusion. Detect such an input and offer to skip the backup files when sending the patches out. * jc/send-email-skip-backup: send-email: detect and offer to skip backup files
2016-05-03Merge branch 'jd/send-email-to-whom'Junio C Hamano
A question by "git send-email" to ask the identity of the sender has been updated. * jd/send-email-to-whom: send-email: fix grammo in the prompt that asks e-mail recipients
2016-04-25send-email: fix grammo in the prompt that asks e-mail recipientsJunio C Hamano
The message, which dates back to the very original version 83b24437 made in 2005, sounds clumsy, grammatically incorrect, and is hard to understand. Reported-by: John Darrington <john@darrington.wattle.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22Merge branch 'ew/send-email-drop-data-dumper'Junio C Hamano
Code clean-up. * ew/send-email-drop-data-dumper: send-email: do not load Data::Dumper
2016-04-22Merge branch 'ew/send-email-readable-message-id'Junio C Hamano
"git send-email" now uses a more readable timestamps when formulating a message ID. * ew/send-email-readable-message-id: send-email: more meaningful Message-ID
2016-04-13send-email: detect and offer to skip backup filesJunio C Hamano
Diligent people save output from format-patch to files, proofread and edit them and then finally send the result out. If the resulting files are sent out with "git send-email 0*", this ends up sending backup files (e.g. 0001-X.patch.backup or 0001-X.patch~) left by their editors next to the final version. Sending them with "git send-email 0*.patch" (if format-patch was run with the standard suffix) would avoid such an embarrassment, but not everybody is careful. After collecting files to be sent (and sorting them if read from a directory), notice when the file being sent out has the same name as the previous file, plus some suffix (e.g. 0001-X.patch was sent, and we are looking at 0001-X.patch.backup or 0001-X.patch~), and the suffix begins with a non-alnum (e.g. ".backup" or "~") and ask if the user really wants to send it out. Once the user skips sending such a "backup" file, remember the suffix and stop asking the same question (e.g. after skipping 0001-X.patch~, skip 0002-Y.patch~ without asking). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06send-email: do not load Data::DumperEric Wong
We never used Data::Dumper in this script. The only reference of it was always commented out and removed over a decade ago in commit 4bc87a28be020a6bf7387161c65ea3d8e4a0228b ("send-email: Change from Mail::Sendmail to Net::SMTP") Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06send-email: more meaningful Message-IDEric Wong
Using a YYYYmmddHHMMSS date representation is more meaningful to humans, especially when used for lookups on NNTP servers or linking to archive sites via Message-ID (e.g. mid.gmane.org or mid.mail-archive.com). This timestamp format more easily gives a reader of the URL itself a rough date of a linked message compared to having them calculate the seconds since the Unix epoch. Furthermore, having the MUA name in the Message-ID seems to be a rare oddity I haven't noticed outside of git-send-email. We already have an optional X-Mailer header field to advertise for us, so extending the Message-ID by 15 characters can make for unpleasant Message-ID-based URLs to archive sites. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18send-email: ignore trailing whitespace in mailrc alias fileJeff King
The regex for parsing mailrc considers everything after the second whitespace to be the email address, up to the end of the line. We have to include whitespace there, because you may have multiple space-separated addresses, each with their own internal quoting. But if there is trailing whitespace, we include that, too. This confuses quotewords() when we try to split the individual addresses, and we end up storing "undef" in our alias list. Later parts of the code then access that, generating perl warnings. Let's tweak our regex to throw away any trailing whitespace on each line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Merge branch 'ew/send-email-mutt-alias-fix' into maintJunio C Hamano
"git send-email" was confused by escaped quotes stored in the alias files saved by "mutt", which has been corrected. * ew/send-email-mutt-alias-fix: git-send-email: do not double-escape quotes from mutt