summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2015-03-03Merge branch 'km/send-email-getopt-long-workarounds'Libravatar Junio C Hamano1-0/+10
Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support "--no-" prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. * km/send-email-getopt-long-workarounds: git-send-email.perl: support no- prefix with older GetOptions
2015-02-25Merge branch 'jc/send-email-sensible-encoding'Libravatar Junio C Hamano1-0/+1
"git send-email" used to accept a mistaken "y" (or "yes") as an answer to "What encoding do you want to use [UTF-8]? " without questioning. Now it asks for confirmation when the answer looks too short to be a valid encoding name. * jc/send-email-sensible-encoding: send-email: ask confirmation if given encoding name is very short
2015-02-16git-send-email.perl: support no- prefix with older GetOptionsLibravatar Kyle J. McKay1-0/+10
Only Perl version 5.8.0 or later is required, but that comes with an older Getopt::Long (2.32) that does not support the 'no-' prefix. Support for that was added in Getopt::Long version 2.33. Since the help only mentions the 'no-' prefix and not the 'no' prefix, add explicit support for the 'no-' prefix to support older GetOptions versions. Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-13send-email: ask confirmation if given encoding name is very shortLibravatar Junio C Hamano1-0/+1
Sometimes people respond "y<ENTER>" (or "yes<ENTER>") when asked this question: Which 8bit encoding should I declare [UTF-8]? We already have a mechanism to avoid accepting a mistyped e-mail address (we ask to confirm when the given address lacks "@" in it); reuse it to trigger the same confirmation when given a very short answer. As a typical charset name is probably at least 4 chars or longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would prevent such a mistake. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07Merge branch 'lh/send-email-hide-x-mailer'Libravatar Junio C Hamano1-3/+8
"git send-email" normally identifies itself via X-Mailer: header in the message it sends out. A new command line flag allows the user to squelch the header. * lh/send-email-hide-x-mailer: test/send-email: --[no-]xmailer tests send-email: add --[no-]xmailer option
2015-01-07Merge branch 'rd/send-email-2047-fix'Libravatar Junio C Hamano1-11/+25
"git send-email" did not handle RFC 2047 encoded headers quite right. * rd/send-email-2047-fix: send-email: handle adjacent RFC 2047-encoded words properly send-email: align RFC 2047 decoding more closely with the spec
2014-12-15send-email: add --[no-]xmailer optionLibravatar Luis Henriques1-3/+8
Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:' header to the email being sent. Signed-off-by: Luis Henriques <henrix@camandro.org> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-15send-email: handle adjacent RFC 2047-encoded words properlyLibravatar Роман Донченко1-10/+16
The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). Signed-off-by: Роман Донченко <dpb@corrigendum.ru> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-15send-email: align RFC 2047 decoding more closely with the specLibravatar Роман Донченко1-11/+19
More specifically: * Add "\" to the list of characters not allowed in a token (see RFC 2047 errata). * Share regexes between unquote_rfc2047 and is_rfc2047_quoted. Besides removing duplication, this also makes unquote_rfc2047 more stringent. * Allow both "q" and "Q" to identify the encoding. * Allow lowercase hexadecimal digits in the "Q" encoding. And, more on the cosmetic side: * Change the "encoded-text" regex to exclude rather than include characters, for clarity and consistency with "token". Signed-off-by: Роман Донченко <dpb@corrigendum.ru> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-send-email: add --transfer-encoding optionLibravatar Paolo Bonzini1-0/+36
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-send-email: delay creation of MIME headersLibravatar Paolo Bonzini1-6/+19
After the next patch, git-send-email will sometimes modify existing Content-Transfer-Encoding headers. Delay the addition of the header to @xh until just before sending. Do the same for MIME-Version, to avoid adding it twice. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-20Merge branch 'mt/send-email-cover-to-cc'Libravatar Junio C Hamano1-0/+16
* mt/send-email-cover-to-cc: t9001: avoid non-portable '\n' with sed test/send-email: to-cover, cc-cover tests git-send-email: two new options: to-cover, cc-cover
2014-04-29git-send-email: two new options: to-cover, cc-coverLibravatar Michael S. Tsirkin1-0/+16
Allow extracting To/Cc addresses from the first patch (typically the cover letter), and use them as To/Cc addresses of the remainder of the series. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-23send-email: windows drive prefix (e.g. C:) appears only at the beginningLibravatar Junio C Hamano1-1/+1
Tighten the regexp used in the "file_name_is_absolute" replacement used on msys to declare that only "[a-zA-Z]:" that appear at the very beginning is a path with a drive-prefix. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-16send-email: recognize absolute path on WindowsLibravatar Erik Faye-Lund1-2/+14
On Windows, absolute paths might start with a DOS drive prefix, which these two checks failed to recognize. Unfortunately, we cannot simply use the file_name_is_absolute helper in File::Spec::Functions, because Git for Windows has an MSYS-based Perl, where this helper doesn't grok DOS drive-prefixes. So let's manually check for these in that case, and fall back to the File::Spec-helper on other platforms (e.g Win32 with native Perl) Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-13Merge branch 'rk/send-email-ssl-cert' into maintLibravatar Junio C Hamano1-1/+2
A recent update to "git send-email" broke platforms where /etc/ssl/certs/ directory exists but cannot be used as SSL_ca_path (e.g. Fedora rawhide). * rk/send-email-ssl-cert: send-email: /etc/ssl/certs/ directory may not be usable as ca_path
2014-01-27Merge branch 'rk/send-email-ssl-cert'Libravatar Junio C Hamano1-1/+2
The "if /etc/ssl/certs/ directory exists, explicitly telling the library to use it as SSL_ca_path" blind-defaulting in "git send-email" broke platforms where /etc/ssl/certs/ directory exists, but it cannot used as SSL_ca_path (e.g. Fedora rawhide). Fix it by not specifying any SSL_ca_path/SSL_ca_file but still asking for peer verification in such a case. * rk/send-email-ssl-cert: send-email: /etc/ssl/certs/ directory may not be usable as ca_path
2014-01-16send-email: /etc/ssl/certs/ directory may not be usable as ca_pathLibravatar Ruben Kerkhof1-1/+2
When sending patches on Fedora rawhide with git-1.8.5.2-1.fc21.x86_64 and perl-IO-Socket-SSL-1.962-1.fc21.noarch, with the following [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = ruben@rubenkerkhof.com smtpserverport = 587 git-send-email fails with: STARTTLS failed! SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/libexec/git-core/git-send-email line 1236. The current code detects the presence of /etc/ssl/certs directory (it actually is a symlink to another directory, but that does not matter) and uses SSL_ca_path to point at it when initializing the connection with IO::Socket::SSL or Net::SMTP::SSL. However, on the said platform, it seems that this directory is not designed to be used as SSL_ca_path. Using a single file inside that directory (cert.pem, which is a Mozilla CA bundle) with SSL_ca_file does work, and also not specifying any SSL_ca_file/SSL_ca_path (and letting the library use its own default) and asking for peer verification does work. By removing the code that blindly defaults $smtp_ssl_cert_path to "/etc/ssl/certs", we can prevent the codepath that treats any directory specified with that variable as usable for SSL_ca_path from incorrectly triggering. This change could introduce a regression for people on a platform whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL somehow fails to use it as SSL_ca_path without being told. Using /etc/ssl/certs directory as SSL_ca_path by default like the current code does would have been hiding such a broken installation without its user needing to do anything. These users can still work around such a platform bug by setting the configuration variable explicitly to point at /etc/ssl/certs. This change should not negate what 35035bbf (send-email: be explicit with SSL certificate verification, 2013-07-18), which was the original change that introduced the defaulting to /etc/ssl/certs/, attempted to do, which is to make sure we do not communicate over insecure connection by default, triggering warning from the library. Cf. https://bugzilla.redhat.com/show_bug.cgi?id=1043194 Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04send-email: set SSL options through IO::Socket::SSL::set_client_defaultsLibravatar Thomas Rast1-2/+5
When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection, passing its ->new all the options that would otherwise go to Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the SSL options). However, while Net::SMTP::SSL replaces the underlying socket class with an SSL socket, it does nothing to allow passing options to that socket. So the SSL-relevant options are lost. Fortunately there is an escape hatch: we can directly set the options with IO::Socket::SSL::set_client_defaults. They will then persist within the IO::Socket::SSL module. Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04send-email: --smtp-ssl-cert-path takes an argumentLibravatar Thomas Rast1-1/+1
35035bb (send-email: be explicit with SSL certificate verification, 2013-07-18) forgot to specify that --smtp-ssl-cert-path takes a string argument. This means that the option could not actually be used as intended. Presumably noone noticed because it's much easier to set it through configs anyway. Add the required "=s". Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-04send-email: pass Debug to Net::SMTP::SSL::newLibravatar Thomas Rast1-0/+1
We forgot to pass the Debug option through to Net::SMTP::SSL->new -- which is the same as Net::SMTP->new. This meant that with security set to SSL, we would never enable debug output. Pass through the flag. Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-10send-email: don't call methods on undefined valuesLibravatar Brian M. Carlson1-1/+1
If SSL verification is enabled in git send-email, we could attempt to call a method on an undefined value if the verification failed, since $smtp would end up being undef. Look up the error string in a way that will produce a helpful error message and not cause further errors. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'rr/send-email-ssl-verify'Libravatar Junio C Hamano1-3/+38
Newer Net::SMTP::SSL module does not want the user programs to use the default behaviour to let server certificate go without verification, so by default enable the verification with a mechanism to turn it off if needed. * rr/send-email-ssl-verify: send-email: be explicit with SSL certificate verification
2013-07-18send-email: be explicit with SSL certificate verificationLibravatar Ramkumar Ramachandra1-3/+38
When initiating an SSL connection without explicitly specifying the SSL certificate verification mode, Net::SMTP::SSL defaults to no verification, but recent versions of the module gives a warning against this use of the default. Enable certificate verification by default, using /etc/ssl/certs as the default path for certificates of certificate authorities. This path can be overriden by the --smtp-ssl-cert-path command line option and the sendemail.smtpSSLCertPath configuration variable. Passing an empty string as the path for CA certificates path disables the SSL certificate verification explicitly, which does not trigger the warning from recent versions of Net::SMTP::SSL. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Helped-by: Brian M. Carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15Merge branch 'bc/send-email-use-port-as-separate-param'Libravatar Junio C Hamano1-2/+4
Pass port number as a separate argument when send-email initializes Net::SMTP, instead of as a part of the hostname, i.e. host:port. This allows GSSAPI codepath to match with the hostname given. * bc/send-email-use-port-as-separate-param: send-email: provide port separately from hostname
2013-07-04send-email: provide port separately from hostnameLibravatar brian m. carlson1-2/+4
If the SMTP port is provided as part of the hostname to Net::SMTP, it passes the combined string to the SASL provider; this causes GSSAPI authentication to fail since Kerberos does not want the port information. Instead, pass the port as a separate argument as is done for SSL connections. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27Merge branch 'mt/send-email-cc-match-fix'Libravatar Junio C Hamano1-2/+3
Logic used by git-send-email to suppress cc mishandled names that need RFC2047 quoting. * mt/send-email-cc-match-fix: send-email: sanitize author when writing From line send-email: add test for duplicate utf8 name
2013-06-20send-email: sanitize author when writing From lineLibravatar Michael S. Tsirkin1-2/+3
sender is now sanitized, but we didn't sanitize author when checking whether From: line is needed in the message body. As a result git started writing duplicate From: lines when author matched sender and has utf8 characters. Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14Merge branch 'mt/send-email-cc-match-fix'Libravatar Junio C Hamano1-8/+15
Logic git-send-email used to suppress cc mishandled names like "A U. Thor" <author@example.xz>, where the human readable part needs to be quoted (the user input may not have the double quotes around the name, and comparison was done between quoted and unquoted strings). * mt/send-email-cc-match-fix: test-send-email: test for pre-sanitized self name t/send-email: test suppress-cc=self with non-ascii t/send-email: add test with quoted sender send-email: make --suppress-cc=self sanitize input t/send-email: test suppress-cc=self on cccmd send-email: fix suppress-cc=self on cccmd t/send-email.sh: add test for suppress-cc=self
2013-06-05send-email: make --suppress-cc=self sanitize inputLibravatar Michael S. Tsirkin1-8/+15
--suppress-cc=self fails to filter sender address in many cases where it needs to be sanitized in some way, for example quoted: "A U. Thor" <author@example.com> To fix, make send-email sanitize both sender and the address it is compared against. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05send-email: fix suppress-cc=self on cccmdLibravatar Michael S. Tsirkin1-1/+1
When cccmd is used, old-style suppress-from filter is applied by the newer suppress-cc=self isn't. Fix this up. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28send-email: remove warning about unset chainreplytoLibravatar Felipe Contreras1-17/+2
Three years and a half is probably more than enough time to give users the opportunity to configure Git to do what they want. If they haven't changed the configuration by now, this warning message is not going to do anything for them anyway. This effectively reverts commit 528fb08 (prepare send-email for smoother change of --chain-reply-to default). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07send-email: make annotate configurableLibravatar Felipe Contreras1-3/+4
Some people always do --annotate, lets not force them to always type that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'rr/send-email-perl-critique'Libravatar Junio C Hamano1-8/+10
Update "git send-email" for issues noticed by PerlCritic. * rr/send-email-perl-critique: send-email: use the three-arg form of open in recipients_cmd send-email: drop misleading function prototype send-email: use "return;" not "return undef;" on error codepaths
2013-03-31send-email: use the three-arg form of open in recipients_cmdLibravatar Ramkumar Ramachandra1-1/+1
Perlcritic does not want to see the trailing pipe in the two-args form of open(), i.e. open my $fh, "$cmd \Q$file\E |"; If $cmd were a single-token command name, it would make a lot more sense to use four-or-more-args form "open FILEHANDLE,MODE,CMD,ARGS" to avoid shell from expanding metacharacters in $file, but we do expect multi-word string in $to_cmd and $cc_cmd to be expanded by the shell, so we cannot rewrite it to open my $fh, "-|", $cmd, $file; for extra safety. At least, by using this in the three-arg form: open my $fh, "-|", "$cmd \Q$file\E"; we can silence Perlcritic, even though we do not gain much safety by doing so. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31send-email: drop misleading function prototypeLibravatar Ramkumar Ramachandra1-4/+6
The subroutine check_file_rev_conflict() is called from two places, both of which expects to pass a single scalar variable and see if that can be interpreted as a pathname or a revision name. It is defined with a function prototype ($) to force a scalar context while evaluating the arguments at the calling site but it does not help the current calling sites. The only effect it has is to hurt future calling sites that may want to build an argument list in an array variable and call it as check_file_rev_confict(@args). Drop the misleading prototype, as Perlcritic suggests. While at it, rename the function to avoid new call sites unaware of this change arising and add a comment clarifying what this function is for. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31send-email: use "return;" not "return undef;" on error codepathsLibravatar Ramkumar Ramachandra1-3/+3
All the callers of "ask", "extract_valid_address", and "validate_patch" subroutines assign the return values from them to a single scalar: $var = subr(...); and "return undef;" in these subroutine can safely be turned into a simpler "return;". Doing so will also future-proof a new caller that mistakenly does this: @foo = ask(...); if (@foo) { ... we got an answer ... } else { ... we did not ... } Note that we leave "return undef;" in validate_address on purpose, even though Perlcritic may complain. The primary "return" site of the function returns whatever is in the scalar variable $address, so it is pointless to change only the other "return undef;" to "return". The caller must be prepared to see an array with a single undef as the return value from this subroutine anyway. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27git-send-email: use git credential to obtain passwordLibravatar Michal Nazarewicz1-28/+43
If smtp_user is provided but smtp_pass is not, instead of prompting for password, make git-send-email use git credential command instead. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14Merge branch 'nz/send-email-headers-are-case-insensitive'Libravatar Junio C Hamano1-5/+5
When user spells "cc:" in lowercase in the fake "header" in the trailer part, send-email failed to pick up the addresses from there. As e-mail headers field names are case insensitive, this script should follow suit and treat "cc:" and "Cc:" the same way. * nz/send-email-headers-are-case-insensitive: git-send-email: treat field names as case-insensitively
2013-01-06git-send-email: treat field names as case-insensitivelyLibravatar Nickolai Zeldovich1-5/+5
Field names like To:, Cc:, etc. are case-insensitive; use a case-insensitive regexp to match them as such. Previously, git-send-email would fail to pick-up the addresses when in-body "fake" headers with different cases (e.g. lowercase "cc:") are manually inserted to the messages it was asked to send, even though the text will still show them. Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29Merge branch 'km/send-email-remove-cruft-in-address'Libravatar Junio C Hamano1-18/+59
* km/send-email-remove-cruft-in-address: git-send-email: allow edit invalid email address git-send-email: ask what to do with an invalid email address git-send-email: remove invalid addresses earlier git-send-email: fix fallback code in extract_valid_address() git-send-email: remove garbage after email address
2012-11-26git-send-email: allow edit invalid email addressLibravatar Krzysztof Mazur1-3/+6
In some cases the user may want to send email with "Cc:" line with email address we cannot extract. Now we allow user to extract such email address for us. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: ask what to do with an invalid email addressLibravatar Krzysztof Mazur1-2/+10
We used to warn about invalid emails and just drop them. Such warnings can be unnoticed by user or noticed after sending email when we are not giving the "final sanity check [Y/n]?" Now we quit by default. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: remove invalid addresses earlierLibravatar Krzysztof Mazur1-13/+39
Some addresses are passed twice to unique_email_list() and invalid addresses may be reported twice per send_message. Now we warn about them earlier and we also remove invalid addresses. This also removes using of undefined values for string comparison for invalid addresses in cc list processing. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26send-email: avoid questions when user has an identLibravatar Felipe Contreras1-6/+1
Currently we keep getting questions even when the user has properly configured his full name and password: Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] And once a question pops up, other questions are turned on. This is annoying. The reason it's safe to avoid this question is because currently the script fails completely when the author (or committer) is not correct, so we won't even be reaching this point in the code. The scenarios, and the current situation: 1) No information at all, no fully qualified domain name fatal: empty ident name (for <felipec@nysa.(none)>) not allowed 2) Only full name fatal: unable to auto-detect email address (got 'felipec@nysa.(none)') 3) Full name + fqdm Who should the emails appear to be from? [Felipe Contreras <felipec@nysa.felipec.org>] 4) Full name + EMAIL Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] 5) User configured 6) GIT_COMMITTER 7) GIT_AUTHOR All these are the same as 4) After this patch: 1) 2) won't change: git send-email would still die 4) 5) 6) 7) will change: git send-email won't ask the user This is good, that's what we would expect, because the identity is explicit. 3) will change: git send-email won't ask the user This is bad, because we will try with an address such as 'felipec@nysa.felipec.org', which is most likely not what the user wants, but the user will get warned by default (confirm=auto), and if not, most likely the sending won't work, which the user would readily note and fix. The worst possible scenario is that such mail address does work, and the user sends an email from that address unintentionally, when in fact the user expected to correct that address in the prompt. This is a very, very, very unlikely scenario, with many dependencies: 1) No configured user.name/user.email 2) No specified $EMAIL 3) No configured sendemail.from 4) No specified --from argument 5) A fully qualified domain name 6) A full name in the geckos field 7) A sendmail configuration that allows sending from this domain name 8) confirm=never, or 8.1) confirm configuration not hitting, or 8.2) Getting the error, not being aware of it 9) The user expecting to correct this address in the prompt In a more likely scenario where 7) is not the case (can't send from nysa.felipec.org), the user will simply see the mail was not sent properly, and fix the problem. The much more likely scenario though, is where 5) is not the case (nysa.(none)), and git send-email will fail right away like it does now. So the likelihood of this affecting anybody seriously is very very slim, and the chances of this affecting somebody slightly are still very small. The vast majority, if not all, of git users won't be affected negatively, and a lot will benefit from this. Tests-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: fix fallback code in extract_valid_address()Libravatar Krzysztof Mazur1-5/+5
In the fallback check, used when Email::Valid is not available, the extract_valid_address() uses $1 without checking for success of matching regex. The $1 variable may still hold the result of previous match, which is the address when email address was in '<>' or be undefined otherwise. Now if match fails undefined value is always returned to indicate error. The same value is used by Email::Valid->address() in that case. Previously 'foo@bar' address was rejected by Email::Valid and fallback, but '<foo@bar>' was rejected by Email::Valid, but accepted by fallback. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: remove garbage after email addressLibravatar Krzysztof Mazur1-0/+4
In some cases it is useful to add additional information after the email address on the Cc: footer in a commit log, for instance: "Cc: Stable kernel <stable@vger.kernel.org> #v3.4 v3.5 v3.6" However, git-send-email refuses to pick up such an invalid address when the Email::Valid perl module is available, or just uses the whole line as the email address. In sanitize_address(), remove everything after the email address, so that the result is a valid email address that makes Email::Valid happy. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-25git-send-email: add rfc2047 quoting for "=?"Libravatar Krzysztof Mazur1-1/+1
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters, but also for any possible rfc2047 in it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: introduce quote_subject()Libravatar Krzysztof Mazur1-6/+19
The quote_rfc2047() always adds RFC2047 quoting. To avoid quoting ASCII subjects, before calling quote_rfc2047() subject must be tested for non-ASCII characters. This patch introduces a new quote_subject() function, which performs the test and calls quote_rfc2047 only if necessary. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: skip RFC2047 quoting for ASCII subjectsLibravatar Krzysztof Mazur1-1/+2
The git-send-email always use RFC2047 subject quoting for files with "broken" encoding - non-ASCII files without Content-Transfer-Encoding, even for ASCII subjects. This is harmless but unnecessarily ugly for people reading the raw headers. This patch skips rfc2047 quoting when the subject does not need it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>