summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
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>
2017-06-01send-email: Net::SMTP::starttls was introduced in v2.34Libravatar Jonathan Nieder1-1/+1
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'Libravatar Junio C Hamano1-19/+35
"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 necessaryLibravatar Dennis Kaarsemaker1-19/+35
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 hookLibravatar Jonathan Tan1-1/+19
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 maintLibravatar Junio C Hamano1-1/+1
"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'Libravatar Junio C Hamano1-1/+1
"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 tagLibravatar Johan Hovold1-1/+1
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 translationLibravatar Vasco Almeida1-7/+9
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 translationLibravatar Vasco Almeida1-40/+47
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 translationLibravatar Vasco Almeida1-17/+17
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 translationLibravatar Vasco Almeida1-22/+32
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'Libravatar Junio C Hamano1-0/+40
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'Libravatar Junio C Hamano1-2/+3
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 recipientsLibravatar Junio C Hamano1-2/+3
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'Libravatar Junio C Hamano1-1/+0
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'Libravatar Junio C Hamano1-2/+3
"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-12send-email: detect and offer to skip backup filesLibravatar Junio C Hamano1-0/+40
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::DumperLibravatar Eric Wong1-1/+0
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-IDLibravatar Eric Wong1-2/+3
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 fileLibravatar Jeff King1-1/+1
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 maintLibravatar Junio C Hamano1-2/+7
"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
2016-01-04git-send-email: do not double-escape quotes from muttLibravatar Eric Wong1-2/+7
mutt saves aliases with escaped quotes in the form of: alias dot \"Dot U. Sir\" <somebody@example.org> When we pass through our sanitize_address routine, we end up with double-escaping: To: "\\\"Dot U. Sir\\\" <somebody@example.org> Remove the escaping in mutt only for now, as I am not sure if other mailers can do this or if this is better fixed in sanitize_address. Cc: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Cc: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21Merge branch 'jk/send-email-ssl-errors'Libravatar Junio C Hamano1-0/+7
Improve error reporting when SMTP TLS fails. * jk/send-email-ssl-errors: send-email: enable SSL level 1 debug output
2015-12-11send-email: enable SSL level 1 debug outputLibravatar John Keeping1-0/+7
If a server's certificate isn't accepted by send-email, the output is: Unable to initialize SMTP properly. Check config and use --smtp-debug. but adding --smtp-debug=1 just produces the same output since we don't get as far as talking SMTP. Turning on SSL debug at level 1 gives: DEBUG: .../IO/Socket/SSL.pm:1796: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:673: fatal SSL error: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:1780: IO::Socket::IP configuration failed IO::Socket::SSL defines level 1 debug as "print out errors from IO::Socket::SSL and ciphers from Net::SSLeay". In fact, it aliases Net::SSLeay::trace which is defined to guarantee silence at level 0 and only emit error messages at level 1, so let's enable it by default. The modification of warnings is needed to avoid a warning about: Name "IO::Socket::SSL::DEBUG" used only once: possible typo Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-04Merge branch 'jk/send-email-complete-aliases'Libravatar Junio C Hamano1-0/+15
Teach send-email to dump mail aliases, so that we can do tab completion on the command line. * jk/send-email-complete-aliases: completion: add support for completing email aliases sendemail: teach git-send-email to dump alias names
2015-12-01Merge branch 'jk/send-email-ca-path'Libravatar Jeff King1-2/+1
Use a safer behavior when we hit errors verifying remote certificates. * jk/send-email-ca-path: send-email: die if CA path doesn't exist
2015-11-24send-email: die if CA path doesn't existLibravatar John Keeping1-2/+1
If the CA path isn't found it's most likely to indicate a misconfiguration, in which case accepting any certificate is unlikely to be the correct thing to do. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20send-email: expand path in sendemail.smtpsslcertpath configLibravatar John Keeping1-1/+1
As it says in the name, the SSL certificate path is a path so treat it as one and support tilde-expansion. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20sendemail: teach git-send-email to dump alias namesLibravatar Jacob Keller1-0/+15
Add an option "--dump-aliases" which changes the default behavior of git-send-email. This mode will simply read the alias files configured by sendemail.aliasesfile and sendemail.aliasfiletype and dump a list of all configured aliases, one per line. The intended use case for this option is the bash-completion script which will use it to autocomplete aliases on the options which take addresses. Add some tests for the new option using various alias file formats. A possible future extension to the alias dump format could be done by extending the --dump-aliases to take an optional argument defining the format to display. This has not been done in this patch as no user of this information has been identified. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2015-11-05Merge branch 'sa/send-email-smtp-batch-data-limit' into maintLibravatar Junio C Hamano1-1/+5
When "git send-email" wanted to talk over Net::SMTP::SSL, Net::Cmd::datasend() did not like to be fed too many bytes at the same time and failed to send messages. Send the payload one line at a time to work around the problem. * sa/send-email-smtp-batch-data-limit: git-send-email.perl: Fixed sending of many/huge changes/patches
2015-10-15Merge branch 'sa/send-email-smtp-batch-data-limit'Libravatar Junio C Hamano1-1/+5
When "git send-email" wanted to talk over Net::SMTP::SSL, Net::Cmd::datasend() did not like to be fed too many bytes at the same time and failed to send messages. Send the payload one line at a time to work around the problem. * sa/send-email-smtp-batch-data-limit: git-send-email.perl: Fixed sending of many/huge changes/patches
2015-09-30git-send-email.perl: Fixed sending of many/huge changes/patchesLibravatar Stefan Agner1-1/+5
Sometimes sending huge patches/commits fail with [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1320. Running the command with --smtp-debug=1 yields to Net::SMTP::SSL: Net::Cmd::datasend(): unexpected EOF on command channel: at /usr/lib/git-core/git-send-email line 1320. [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1320. Stefan described it in his mail like this: It seems to me that there is a size limit, after cutting down the patch to ~16K, sending started to work. I cut it twice, once by removing lines from the head and once from the bottom, in both cases at the size of around 16K I could send the patch. See also original report: http://permalink.gmane.org/gmane.comp.version-control.git/274569 Reported-by: Juston Li <juston.h.li@gmail.com> Tested-by: Markos Chandras <hwoarang@gentoo.org> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-21Merge branch 'bn/send-email-smtp-auth-error-message-fix'Libravatar Junio C Hamano1-1/+1
Fix a minor regression brought in to "git send-email" by a recent addition of the "--smtp-auth" option. * bn/send-email-smtp-auth-error-message-fix: send-email: fix uninitialized var warning for $smtp_auth
2015-09-21send-email: fix uninitialized var warning for $smtp_authLibravatar Brian Norris1-1/+1
On the latest version of git-send-email, I see this error just before running SMTP auth (I didn't provide any --smtp-auth= parameter): Use of uninitialized value $smtp_auth in pattern match (m//) at \ /home/briannorris/git/git/git-send-email.perl line 1139. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-26Merge branch 'jv/send-email-selective-smtp-auth'Libravatar Junio C Hamano1-1/+25
"git send-email" learned a new option --smtp-auth to limit the SMTP AUTH mechanisms to be used to a subset of what the system library supports. * jv/send-email-selective-smtp-auth: send-email: provide whitelist of SMTP AUTH mechanisms
2015-08-17send-email: provide whitelist of SMTP AUTH mechanismsLibravatar Jan Viktorin1-1/+25
When sending an e-mail, the client and server must agree on an authentication mechanism. Some servers (due to misconfiguration or a bug) deny valid credentials for certain mechanisms. In this patch, a new option --smtp-auth and configuration entry smtpAuth are introduced. If smtp_auth is defined, it works as a whitelist of allowed mechanisms for authentication selected from the ones supported by the installed SASL perl library. Signed-off-by: Jan Viktorin <viktorin@rehivetech.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'rl/send-email-aliases'Libravatar Junio C Hamano1-28/+22
"git send-email" now performs alias-expansion on names that are given via --cccmd, etc. This round comes with a lot more enhanced e-mail address parser, which makes it a bit scary, but as long as it works as designed, it makes it wonderful ;-). * rl/send-email-aliases: send-email: suppress meaningless whitespaces in from field send-email: allow multiple emails using --cc, --to and --bcc send-email: consider quote as delimiter instead of character send-email: reduce dependencies impact on parse_address_line send-email: minor code refactoring send-email: allow use of aliases in the From field of --compose mode send-email: refactor address list process t9001-send-email: refactor header variable fields replacement send-email: allow aliases in patch header and command script outputs t9001-send-email: move script creation in a setup test
2015-07-07send-email: suppress meaningless whitespaces in from fieldLibravatar Remi Lespinet1-0/+1
Remove leading and trailing whitespaces in from field before interepreting it to improve consistency with other options. The split_addrs function already take care of trailing and leading whitespaces for to, cc and bcc fields. The from option now: - has the same behavior when passing arguments like " jdoe@example.com ", "\t jdoe@example.com " or "jdoe@example.com". - interprets aliases in string containing leading and trailing whitespaces such as " alias" or "alias\t" like other options. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: allow multiple emails using --cc, --to and --bccLibravatar Remi Lespinet1-15/+2
Accept a list of emails separated by commas in flags --cc, --to and --bcc. Multiple addresses can already be given by using these options multiple times, but it is more convenient to allow cutting-and-pasting a list of addresses from the header of an existing e-mail message, which already lists them as comma-separated list, as a value to a single parameter. The following format can now be used: $ git send-email --to='Jane <jdoe@example.com>, mike@example.com' Remove the limitation imposed by 79ee555b (Check and document the options to prevent mistakes, 2006-06-21) which rejected every argument with comma in --cc, --to and --bcc. Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: consider quote as delimiter instead of characterLibravatar Remi Lespinet1-2/+4
Do not consider quote inside a recipient name as character when they are not escaped. This interprets: "Jane" "Doe" <jdoe@example.com> as: "Jane Doe" <jdoe@example.com> instead of: "Jane\" \"Doe" <jdoe@example.com> Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: reduce dependencies impact on parse_address_lineLibravatar Remi Lespinet1-1/+1
parse_address_line had not the same behavior whether the user had Mail::Address or not. Teach parse_address_line to behave like Mail::Address. When the user input is correct, this implementation behaves exactly like Mail::Address except when there are quotes inside the name: "Jane Do"e <jdoe@example.com> In this case the result of parse_address_line is: With M::A : "Jane Do" e <jdoe@example.com> Without : "Jane Do e" <jdoe@example.com> When the user input is not correct, the behavior is also mostly the same. Unlike Mail::Address, this doesn't parse groups and recursive commentaries. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30send-email: minor code refactoringLibravatar Remi Lespinet1-3/+3
Group expressions in a single if statement. This avoid checking multiple time if the variable $sender is defined. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30send-email: allow use of aliases in the From field of --compose modeLibravatar Remi Lespinet1-2/+2
Aliases were expanded before considering the From field of the --compose option. This is inconsistent with other fields (To, Cc, ...) which already support aliases. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>