summaryrefslogtreecommitdiff
path: root/Documentation/technical/shallow.txt
diff options
context:
space:
mode:
authorLibravatar brian m. carlson <sandals@crustytoothpaste.net>2018-07-08 22:17:12 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-07-09 10:55:12 -0700
commite67a228cd8afa7a645a321df90393deceaa57a0e (patch)
tree9ab39ce9c32007bbdbc8d96740fc3cd5c49638b2 /Documentation/technical/shallow.txt
parentsend-email: accept long lines with suitable transfer encoding (diff)
downloadtgif-e67a228cd8afa7a645a321df90393deceaa57a0e.tar.xz
send-email: automatically determine transfer-encoding
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>
Diffstat (limited to 'Documentation/technical/shallow.txt')
0 files changed, 0 insertions, 0 deletions