Git 2.3.0（2015 年 2 月）将提出另一个新选项：--transfer-encoding为了指定要使用的传输编码 (quoted-printable, 8bit, base64)，而不是仅依赖 --keep-cr.
git send-email手册页。
git am手册页。
请参阅Paolo Bonzini ( )的提交 8d81408：bonzini
git-send-email: 添加--transfer-encoding选项
邮件列表线程git am详细说明了在以 CRLF 行结尾的存储库中应用带有“”的补丁时出现的问题。
在线程中的示例中，存储库源自“ git-svn”，因此无法使用core.eol它和它的朋友。
现在，最好的选择是使用“ git am --keep-cr”。
但是，当补丁创建新文件时，补丁应用进程将拒绝新文件，因为它找到的是“ /dev/null\r”字符串而不是“ /dev/null”。
问题是SMTP 传输是 CRLF-unsafe。
通过电子邮件发送补丁与通过“”传递补丁相同dos2unix | unix2dos。
新引入的 CRLF 通常是透明的，因为git-am剥离了它们。该keepcr=true设置保留了它们，但它主要是偶然工作的git am，在具有混合 LF 和 CRLF 行结尾的存储库中具有“”工作流将是非常有问题的。
对此的MIME 解决方案是引用可打印传输编码。
这不是我们想要默认启用的东西，因为它使收到的电子邮件看起来很可怕。
但是，它非常适合在存储库中存储 CRLF 行结尾的项目。
引用打印的唯一缺点是，如果维护者使用“”，引用打印补丁将无法应用git am --keep-cr。
这是因为解码后的补丁将在行尾有两个回车符。
因此，还要添加对base64 传输编码的支持，这使得收到的电子邮件完全不可能在MUA（邮件用户代理）之外查看，但确实可以正常工作。
该补丁覆盖了所有基础，包括仍然生活在 80 年代后期的用户，还提供了 7 位内容传输编码，拒绝发送包含非 ASCII 字符的电子邮件。
最后，“8bit”将添加一个 Content-Transfer-Encoding 标头，否则什么也不做。
git send-email 的文档现在将包括：
--transfer-encoding=(7bit|8bit|quoted-printable|base64)
指定用于通过 SMTP 发送邮件的传输编码。
遇到非 ASCII 消息时，7bit 将失败。
当存储库包含包含回车的文件时，Quoted-printable 可能很有用，但会使原始补丁电子邮件文件（从 MUA 保存）更难以手动检查。
默认是 ' sendemail.transferEncoding' 配置值的值；如果未指定，git将使用 8bit 并且不添加 Content-Transfer-Encoding 标头。
在 Git 2.32（2021 年第二季度）中，“ git mailinfo” （man）（因此“ git am” （man））学习了“ --quoted-cr”选项来控制如何处理以 CRLF 结尾的以 base64 或 qp 包装的行。
请参阅Đoàn Trần Công Danh ( )的提交 59b519a、提交 133a4fd、提交 f1aa299、提交 0b68956（2021 年 5 月 10 日）和提交 dd9323b、提交 d582992（2021 年 5 月 6 日） 。（由Junio C Hamano 合并 -- --在提交 483932a中，2021 年 5 月 16 日）sgn
gitster
mailinfo: 如果在解码的 base64/QP 电子邮件中发现 CRLF，则发出警告
签字人：Đoàn Trần Công Danh
当 SMTP 服务器收到 8 位电子邮件消息时，可能只有 LF 作为行尾，其中一些决定将所述 LF 更改为 CRLF。
一些邮件列表软件在收到 8 位电子邮件消息时，决定将这些消息编码为 base64 或引用打印。
如果一封电子邮件通过上述邮件服务器传输，然后由此类邮件列表软件分发，收件人将收到一封电子邮件，其中包含一个带有 CRLF 编码的补丁，该补丁被编码在另一个编码中。
因此，这样的 CR（在 CRLF 中）不能被“ mailsplit”删除。
因此，无法干净地应用邮寄的补丁。在野外已经观察到
这样的事故。
如果找到这样的 CR（作为 CRLF 的一部分），让我们给我们的用户一些警告，而不是默默地拒绝这些消息。
警告将是：
warning: quoted CRLF detected