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

Merge branch 'km/send-email-getopt-long-workarounds'

2015-03-03T22:37:03Z

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

Merge branch 'jc/send-email-sensible-encoding'

2015-02-25T23:40:19Z

"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

git-send-email.perl: support no- prefix with older GetOptions

2015-02-16T21:26:51Z

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 Signed-off-by: Kyle J. McKay Tested-by: Tom G. Christensen Signed-off-by: Junio C Hamano

send-email: ask confirmation if given encoding name is very short

2015-02-13T20:20:25Z

Sometimes people respond "y" (or "yes") 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

Merge branch 'lh/send-email-hide-x-mailer'

2015-01-07T21:07:27Z

"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

Merge branch 'rd/send-email-2047-fix'

2015-01-07T21:06:47Z

"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

send-email: add --[no-]xmailer option

2014-12-15T23:17:25Z

Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:' header to the email being sent. Signed-off-by: Luis Henriques Acked-by: Eric Wong Signed-off-by: Junio C Hamano

send-email: handle adjacent RFC 2047-encoded words properly

2014-12-15T17:06:40Z

The RFC says that they are to be concatenated after decoding (i.e. the intervening whitespace is ignored). Signed-off-by: Роман Донченко Acked-by: Jeff King Signed-off-by: Junio C Hamano

send-email: align RFC 2047 decoding more closely with the spec

2014-12-15T17:06:39Z

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: Роман Донченко Acked-by: Jeff King Signed-off-by: Junio C Hamano

git-send-email: add --transfer-encoding option

2014-11-25T22:00:15Z

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 Signed-off-by: Junio C Hamano