summaryrefslogtreecommitdiff
path: root/Documentation/git-send-email.txt
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2014-11-25 14:00:27 (GMT)
committerJunio C Hamano <gitster@pobox.com>2014-11-25 22:00:15 (GMT)
commit8d8140843501107c92e2f9a5acb60ee136352c1f (patch)
tree2eda57e5aa49f7ecc457e0385538e7b2258e88cf /Documentation/git-send-email.txt
parentbb29456c89599acfc3ef3046e6a55ce0f48c9865 (diff)
downloadgit-8d8140843501107c92e2f9a5acb60ee136352c1f.zip
git-8d8140843501107c92e2f9a5acb60ee136352c1f.tar.gz
git-8d8140843501107c92e2f9a5acb60ee136352c1f.tar.bz2
git-send-email: add --transfer-encoding option
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>
Diffstat (limited to 'Documentation/git-send-email.txt')
-rw-r--r--Documentation/git-send-email.txt10
1 files changed, 10 insertions, 0 deletions
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index a60776e..a9efa5c 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -131,6 +131,16 @@ Note that no attempts whatsoever are made to validate the encoding.
Specify encoding of compose message. Default is the value of the
'sendemail.composeencoding'; if that is unspecified, UTF-8 is assumed.
+--transfer-encoding=(7bit|8bit|quoted-printable|base64)::
+ Specify the transfer encoding to be used to send the message over SMTP.
+ 7bit will fail upon encountering a non-ASCII message. quoted-printable
+ can be useful when the repository contains files that contain carriage
+ returns, but makes the raw patch email file (as saved from a MUA) much
+ harder to inspect manually. base64 is even more fool proof, but also
+ even more opaque. Default is the value of the 'sendemail.transferEncoding'
+ configuration value; if that is unspecified, git will use 8bit and not
+ add a Content-Transfer-Encoding header.
+
Sending
~~~~~~~