git send-email 未知选项 --transfer-encoding答案

【问题标题】：git send-email unknown option --transfer-encodinggit send-email 未知选项 --transfer-encoding
【发布时间】：2017-01-17 06:55:44
【问题描述】：

我正在尝试使用git send-email 发送补丁。我有想以纯文本形式发送的附件。我正在尝试使用 --transfer-encoding 选项。但是，我收到以下错误：

fatal: unrecognized argument: --transfer-encoding=7bit
format-patch -o /tmp/cPcJzwsREr --transfer-encoding=7bit: command returned error: 128

编辑：好像是版本问题。该选项不适用于v1.9.1。但它适用于v2.7.4 的git-email 包。

我正在尝试发送一系列补丁，这些补丁必须为每封邮件使用不同的主题前缀。我正在尝试使用--chain-reply-to 和--in-reply-to。我正在执行以下命令：

    git send-email --to=<email> --suppress-cc=self --transfer-encoding=7bit --compose-encoding=7bit ./patches/<patch_1>
    git send-email --to=<email> --suppress-cc=self --transfer-encoding=7bit --compose-encoding=7bit --chain-reply-to --in-reply-to=<message_id_of_previous_mail> ./patches/<patch_2>
    git send-email --to=<email> --suppress-cc=self --transfer-encoding=7bit --compose-encoding=7bit --chain-reply-to --in-reply-to=<message_id_of_previous_mail> ./patches/<patch_id>

我希望电子邮件显示为：

Mail 1
|--> Mail 2
     |--> Mail 3

但是，我在收件箱中收到了 3 封不同的邮件。尖括号中的值是占位符，在执行命令时我在它们的位置上有实际值。你能帮帮我吗？

【问题讨论】：

是什么让您认为有--transfer-encoding 选项？见kernel.org/pub/software/scm/git/docs/git-format-patch.html
您使用的完整命令是什么？请将其编辑到问题中。
（我应该补充一点，git send-email 有有--transfer-encoding，但git format-patch 没有。所以正如@halfer 所说，我们需要看看你是什么实际上正在运行。）

标签： git email

【解决方案1】：

发送电子邮件有一个传输编码，但仅从 Git v2.3.0-rc0（2014 年 12 月）开始

见commit 8d81408、commit bb29456（2014 年 11 月 25 日）Paolo Bonzini (bonzini)。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 2374f1d，2014 年 12 月 22 日）}

“git send-email”学会了“--transfer-encoding”选项强制非故障 Content-Transfer-Encoding 标头（例如 base64）。

在您的情况下，使用 Git 2.19（2018 年 7 月）会更容易

参见brian m. carlson (bk2204)commit fa29f36、commit e67a228、commit f2d06fb、commit 7a36987（2018 年 7 月 8 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 7633ff4，2018 年 7 月 24 日）}

默认情况下，“git send-email”发送的消息的内容传输编码为 8bit，当出现超过 RFC 5322/2822 限制的超长行时，这可能会导致问题。

引入了一个新选项“auto”，当负载中有这样一行时自动切换到quoted-printable，并将其设为默认值。

但是，这引入了一些回归，Git 2.23（2019 年第三季度）将修复它们。

由于“git send-email”学会了将“auto”作为transfer-encoding 的值，它错误地停止了赋予配置变量 sendemail.transferencoding 和/或sendemail.<ident>.transferencoding 的值。
这已被更正为（最终）重做设置默认值、读取配置和命令行选项的顺序。

请参阅commit 3ff1504、commit 564eba4、commit a8aea5d、commit 2554dd1（2019 年 5 月 17 日）和commit 3494dfd、commit e60f6d1、commit c573572（2019 年 5 月 9 日）Ævar Arnfjörð Bjarmason (avar)。
^{（于 2019 年 6 月 13 日由 Junio C Hamano -- gitster -- 合并于 commit 86d2271）}

检查你的情况，如果链接在最新版本中效果更好。

另请参阅 Git v1.7.4-rc0（2010 年 11 月）中最新的 In-Reply-To 修复示例，其中最初的 In-Reply-To 仅适用于第一封电子邮件。

见commit db54c8e（2010 年 11 月 12 日）Antonio Ospite (ao2)。
请参阅 Junio C Hamano (gitster) 的 commit 54aae5e（2010 年 10 月 19 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 0153043，2010 年 11 月 24 日）}

--in-reply-to=<identifier>::

使第一封邮件（或所有带有--no-thread 的邮件）显示为对给定 Message-Id 的回复，这样可以避免中断线程以提供新的补丁系列。

第二封及后续邮件将根据以下规定作为回复发送 --[no]-chain-reply-to 设置。

【讨论】：