名称（Name）

git-format-patch  - 为电子邮件提交准备补丁

概要

git format-patch [-k] [(-o|--output-directory) <dir> | --stdout]                   [--no-thread | --thread[=<style>]]                   [(--attach|--inline)[=<boundary>] | --no-attach]                   [-s | --signoff]                   [--signature=<signature> | --no-signature]                   [--signature-file=<file>]                   [-n | --numbered | -N | --no-numbered]                   [--start-number <n>] [--numbered-files]                   [--in-reply-to=Message-Id] [--suffix=.<sfx>]                   [--ignore-if-in-upstream]                   [--rfc] [--subject-prefix=Subject-Prefix]                   [(--reroll-count|-v) <n>]                   [--to=<email>] [--cc=<email>]                   [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]                   [<common diff options>]                   [ <since> | <revision range> ]

描述

每个提交准备每个提交的补丁文件，格式化为类似于 UNIX 邮箱格式。这个命令的输出很方便用于电子邮件提交或用于git am。

有两种方式可以指定对哪些提交进行操作。

1. 一次提交（<since>）指定通向当前分支尖端的不在历史中导致<since>输出的提交。

2. 通用<修订范围>表达式（参见 gitrevisions [7]中的“指定修订”一节）意味着指定范围内的提交。

第一条规则优先于单个<commit>的情况。要应用第二条规则，即格式化从历史开始直到<commit>的所有内容，请使用\--root选项：git format-patch --root <commit>。如果你只想格式化<commit>本身，你可以这样做git format-patch -1 <commit>。

默认情况下，每个输出文件都从1开始依次编号，并使用提交消息的第一行（按路径名安全性）作为文件名。使用该--numbered-files选项，输出文件名称将仅为数字，而不会附加提交的第一行。除非--stdout指定了选项，否则输出文件的名称将打印到标准输出。

如果-o指定，则输出文件将在<dir>中创建。否则，它们将在当前工作目录中创建。默认路径可以使用format.outputDirectory配置选项进行设置。该-o选项优先format.outputDirectory。要将补丁存储在当前工作目录中，即使在format.outputDirectory其他位置使用也是如此-o .。

默认情况下，单个补丁的主题是“PATCH”，接下来是从提交消息到第一个空行的连接（请参阅 git-commit [1]的讨论部分））。

当输出多个音色时，主题前缀将改为“PATCH n / m”。要强制为单个补丁添加1/1，请使用-n。要从主题中省略修补程序编号，请使用-N。

如果给定--thread，git-format-patch将生成In-Reply-To并References标题使第二个和后续的补丁邮件显示为对第一个邮件的答复; 这也会生成一个Message-Id头引用。

选项

-p   --no-stat

无需任何 diffstats 即可生成简单的修补程序。

-U<n>   --unified=<n>

使用<n>行上下文生成差异，而不是通常的三行。

--indent-heuristic   --no-indent-heuristic

这些是为了帮助调试和调整实验启发式（默认情况下是关闭的），这些启发式技术改变了差异边界以使修补程序更易于阅读。

--minimal

花费额外的时间来确保生成最小可能的差异。

--patience

使用“耐心差异”算法生成差异。

--histogram

使用“直方图差异”算法生成差异。

--diff-algorithm={patience|minimal|histogram|myers}

选择一种差异算法。变体如下：

default, myers

基本的贪婪 diff 算法。目前，这是默认设置。

minimal

花费额外的时间来确保生成最小可能的差异。

patience

生成补丁时使用“耐心差异”算法。

histogram

该算法将耐心算法扩展为“支持低出现率的通用元素”。

例如，如果您将 diff.algorithm 变量配置为非默认值并且想要使用默认值，那么您必须使用--diff-algorithm=default选项。

--stat[=<width>[,<name-width>,<count>]]

生成一个 diffstat。默认情况下，文件名部分使用尽可能多的空间，其余部分使用图形部分。最大宽度默认为终端宽度，如果未连接到终端，则最大宽度为80列，并且可以被覆盖<width>。文件名部分的宽度可以通过<name-width>逗号后面的另一个宽度来限制。图形部分的宽度可以通过使用--stat-graph-width=<width>（影响所有生成统计图的命令）或通过设置diff.statGraphWidth=<width>（不影响git format-patch）来限制。通过给出第三个参数<count>，可以将输出限制在第一<count>行，...如果还有更多的话。

这些参数也可以单独设置--stat-width=<width>，--stat-name-width=<name-width>和--stat-count=<count>。

--numstat

类似于--stat，但显示十进制表示法中添加和删除的行数以及不带缩写的路径名，以使其更加机器友好。对于二进制文件，输出两个-而不是说0 0。

--shortstat

只输出--stat包含修改文件总数的格式的最后一行，以及添加和删除行的数量。

--dirstat=<param1,param2,…>

输出每个子目录的相对变化量分布。--dirstat可以通过传递逗号分隔的参数列表来定制行为。默认值由diff.dirstat配置变量控制（请参阅 git-config [1]）。以下参数可用：

changes

通过计算已从源中删除或添加到目标的行来计算 dirstat 数字。这会忽略文件中纯代码移动的数量。换句话说，重新排列文件中的行数不会与其他更改一样多。这是没有给出参数时的默认行为。

lines

通过执行常规基于行的差异分析来计算dirstat数字，并将删除/添加的行数相加。（对于二进制文件，取而代之的是计算64字节的块，因为二进制文件没有自然的行概念）。这是一种--dirstat比changes行为更为昂贵的行为，但它可以像其他更改一样计算文件中重新排列的行数。结果输出与您从其他--*stat选项中获得的结果一致。

files

通过计算更改的文件数量来计算 dirstat 数字。 dirstat 分析中每个更改的文件都相同。这是计算上最便宜的--dirstat行为，因为它不必查看文件内容。

cumulative

计数父目录的子目录中的更改。请注意，使用时cumulative，报告的百分比总和可能超过100％。默认（非累积）行为可以用noncumulative参数指定。

<limit>

整数参数指定截断百分比（默认为3％）。输出中不显示贡献小于此百分比的目录。

示例：以下内容将计数已更改的文件，同时忽略占已更改文件总数少于10％的目录，并累积父目录中的子目录计数：--dirstat=files,10,cumulative。

--summary

输出扩展头信息的精简摘要，如创建，重命名和模式更改。

--no-renames

关闭重命名检测，即使配置文件提供了默认设置。

--full-index

在生成补丁格式输出时，在“索引”行上显示完整的映像前和映像后 blob 对象名称，而不是第一批字符。

--binary

除了--full-index输出可以应用的二进制差异git-apply。

--abbrev=<n>

不是在 diff-raw 格式输出和 diff-tree 标题行中显示完整的40字节十六进制对象名称，只显示部分前缀。这与--full-index上面的选项无关，后者控制 diff-patch 输出格式。非默认的位数可以用指定--abbrev=<n>。

-B<n>   --break-rewrites[=<n>]

将完全重写更改分解为删除和创建对。这有两个目的：

它影响到一种改变的方式，这种改变相当于整个文件的重写，而不是像一系列删除和插入混合在一起，只有几行文本与上下文相匹配，但是作为一个单一的删除旧的一切，随后是一个单次插入所有新事物，并且数字m控制-B选项的这个方面（默认为60％）。-B/70%指定只有少于30％的原始数据应保留在Git的结果中，以便将其视为全部重写（否则结果补丁将是一系列与上下文行混合的删除和插入）。

与-M 一起使用时，完全重写的文件也被认为是重命名的来源（通常-M 仅考虑作为重命名源消失的文件），并且该数字n控制着-B选项的这个方面（默认为50％）。-B20%指定添加和删除相对于文件大小的20％或更多的更改有资格作为重命名为其他文件的可能来源。

-M<n>   --find-renames=<n>

检测重命名。如果n被指定，则它是相似度指数的阈值（即与文件大小相比的添加/删除量）。例如，-M90%如果超过90％的文件没有改变，Git 应该考虑删除/添加对是一个重命名。如果没有%符号，该数字应作为分数读取，并在其前面加小数点。即，-M5变成0.5，并且因此是相同的-M50%。同样的，-M05也是一样的-M5%。要将检测限制为精确重命名，请使用-M100%。默认相似度指数为50％。

-C<n>   --find-copies=<n>

检测副本以及重命名。另见--find-copies-harder。如果n被指定，它的含义与-M<n>。

--find-copies-harder

出于性能原因，默认情况下，-C只有当副本的原始文件在相同的变更集中被修改时，选项才会查找副本。该标志使命令检查未修改的文件作为复制源的候选项。对于大型项目来说这是一项非常昂贵的操作，因此请谨慎使用。给予多个-C选项具有相同的效果。

-D  - 不可逆 - 删除 （--irreversible-delete ）

省略原图像进行删除，即仅打印标题，但不打印原像和之间的差异/dev/null。由此产生的补丁不适用于patch或git apply; 这仅适用于那些想专注于更改后查看文本的人。另外，输出显然缺乏足够的信息来反向应用这样的补丁，甚至是手动的，因此也就是选项的名称。

在与-B删除/创建对的删除部分一起使用时，还要省略原像。

-l<num>

在-M和-C选项需要为O（n ^ 2）的处理时间，其中n是/复制目标潜在的重命名的数目。如果重命名/复制目标的数量超过指定的数量，则此选项可防止重命名/复制检测运行。

-O<orderfile>

控制文件在输出中出现的顺序。这覆盖了diff.orderFile配置变量（请参阅git-config [1]）。取消diff.orderFile，使用-O/dev/null。

输出顺序由<orderfile>中的全局模式顺序决定。所有具有与第一个模式相匹配的路径名的文件将首先输出，接下来将输出所有具有匹配第二个模式（但不是第一个）的路径名的文件，依此类推。最后输出所有不匹配任何模式的路径名的文件，就好像文件末尾有一个隐含的匹配模式一样。如果多个路径名具有相同的排名（它们匹配相同的模式但没有更早的模式），则它们的输出顺序相对于彼此是正常顺序。

按以下方式解析<orderfile>：

• 空白行被忽略，所以它们可以用作分隔符以提高可读性。

• 以散列（“ #”）开头的行会被忽略，因此它们可以用于注释。\如果以散列开头，则在模式的开头添加反斜杠（“ ”）。

• 每隔一行包含一个模式。

模式与没有 FNM_PATHNAME 标志的 fnmantch（3）使用的模式具有相同的语法和语义，但如果删除任何数量的最终路径名组件都与模式匹配，则路径名也与模式匹配。例如，模式“ foo*bar”匹配“ fooasdfbar”和“ foo/bar/baz/asdf”但不是“ foobarx”。

-a   --text

将所有文件视为文本。

--ignore-space-at-eol

忽略 EOL 中的空白变化。

-b   --ignore-space-change

忽略空白量的变化。这会忽略行结束处的空白，并认为一个或多个空白字符的所有其他序列是等价的。

-w --ignore-all-space

比较行时忽略空格。即使一行有空白，而另一行没有空白，这也会忽略差异。

--ignore-blank-lines

忽略其行全部空白的更改。

--inter-hunk-context=<lines>

显示差异 hunk 之间的上下文，直到指定的行数，从而融合彼此接近的 hunk。diff.interHunkContext如果配置选项未设置，则默认为0或0。

-W  - 功能上下文 （--function-context ）

显示整个周围的变化功能。

--ext-diff

允许执行一个外部比较助手。如果你用 gitattributes [5]设置外部差异驱动程序，你需要在 git-log [1]和朋友中使用这个选项。

--no-ext-diff

禁止外部差异驱动程序。

--textconv   --no-textconv

在比较二进制文件时，允许（或不允许）运行外部文本转换过滤器。有关详细信息，请参阅 gitattributes [5]。由于 textconv 过滤器通常是单向转换，因此生成的差异适合人类消费，但无法应用。出于这个原因，默认情况下，textconv 过滤器仅针对 git-diff [1]和 git-log [1]启用，但不适用于 git-format-patch [1]或 diff plumbing命令。

--ignore-submodules=<when>

忽略差异代中子模块的更改。<when>可以是“none”，“untracked”，“dirty”或“all”，这是默认设置。如果子模块包含未跟踪或已修改的文件，或者 HEAD 与超级项目中记录的提交不同，并且可用于覆盖ignoregit-config [1]或 gitmodules [5]中的任何选项设置，则使用“none” ]。当使用“未跟踪”时，如果子模块仅包含未跟踪内容（但仍然针对修改内容进行扫描），则子模块不会被视为脏。使用“dirty”会忽略对子模块工作树的所有更改，只会显示超级项目中存储的提交更改（这是1.7.0之前的行为）。使用“全部”

--src-prefix=<prefix>

显示给定的源前缀而不是“a /”。

--dst-prefix=<prefix>

显示给定的目的地前缀而不是“b /”。

--no-prefix

不要显示任何来源或目的地前缀。

--line-prefix=<prefix>

为每行输出预留一个额外的前缀。

--ita-invisible-in-index

默认情况下，由“git add -N”添加的条目显示为“git diff”中的现有空文件和“git diff --cached”中的新文件。该选项使得该条目在“git diff”中显示为新文件，而在“git diff --cached”中不存在。这个选项可以恢复--ita-visible-in-index。这两个选项都是实验性的，可以在将来删除。

有关这些常用选项的更详细的解释，请参阅 gitdiffcore [7]。

-<n>

从最顶端的<n>提交中准备补丁。

-o <dir> --output-directory <dir>

使用<dir>来存储结果文件，而不是当前的工作目录。

-n   --numbered

以[PATCH n/m]格式输出名称，即使只有一个补丁。

-N   --no-numbered

以[PATCH]格式输出名称。

--start-number <n>

从<n>开始编号，而不是1。

--numbered-files

输出文件名将是一个简单的数字序列，不需要追加提交的默认第一行。

-k   --keep-subject

不要[PATCH]从提交日志消息的第一行剥离/添加。

-s   --signoff

使用自己的提交者身份将Signed-off-by:行添加到提交消息中。有关更多信息，请参阅git-commit [1]中的signoff选项。

--stdout

以 mbox 格式打印所有提交到标准输出，而不是为每个文件创建一个文件。

--attach=<boundary>

创建多部分/混合附件，第一部分是第二部分中的提交消息和补丁本身Content-Disposition: attachment。

--no-attach

禁用创建附件，覆盖配置设置。

--inline=<boundary>

创建多部分/混合附件，第一部分是第二部分中的提交消息和补丁本身Content-Disposition: inline。

--thread=<style>   --no-thread

控制添加In-Reply-To和References标题以使第二个和后续邮件显示为对第一个的回复。还控制生成Message-Id头引用。

可选的<style>参数可以是shallow或deep。shallow线程使得每一封邮件都可以回复该系列的头部，头部从封面信件，--in-reply-to第一个补丁邮件中按顺序选择。deep线程使每个邮件回复到前一个邮件。

默认值是--no-thread，除非format.thread配置已设置。如果--thread未指定样式，则默认为由format.threadif 指定的样式，否则shallow。

请注意，默认设置git send-email是线程邮件本身。如果你想git format-patch照顾线程，你需要确保禁用线程git send-email。

--in-reply-to=Message-Id

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

--ignore-if-in-upstream

请勿在<until> .. <since>中包含与提交相匹配的修补程序。这将检查从<since>但不是从<until>到达的所有修补程序，并将它们与正在生成的修补程序进行比较，并且忽略匹配的任何修补程序。

--subject-prefix=<Subject-Prefix>

而不是[PATCH]主题行中的标准前缀，而是使用[<Subject-Prefix>]。这允许对补丁序列进行有用的命名，并且可以与--numbered选项结合使用。

--rfc

别名--subject-prefix="RFC PATCH"。RFC 意思是“征求意见”; 在发送实验性补丁以供讨论而不是应用时使用它。

-v <n>   --reroll-count=<n>

将该系列标记为该主题的第n次迭代。输出文件名已v<n>添加到它们，并且主题前缀（缺省情况下为“PATCH”，但可通过--subject-prefix选项配置）已v<n>附加到它。例如--reroll-count=4可能会产生v4-0001-add-makefile.patch具有“主题：PATCH v4 1/20添加makefile”的文件。

--to=<email>

将To:标题添加到电子邮件标题。这是除了任何配置的标题之外，可能会多次使用。否定形式--no-to丢弃To:迄今为止添加的所有头文件（来自配置或命令行）。

--cc=<email>

将Cc:标题添加到电子邮件标题。这是除了任何配置的标题之外，可能会多次使用。否定形式--no-cc丢弃Cc:迄今为止添加的所有头文件（来自配置或命令行）。

--from   --from=<ident>

ident在From:每个提交电子邮件的标题中使用。如果提交的作者标识与提供的文本不相同，则在原始作者的邮件正文中ident放置一个From:标题。如果没有ident给出，请使用提交者标识。

请注意，此选项仅在您实际发送电子邮件并希望将自己标识为发件人时有用，但保留原作者（并且git am将正确拾取主体内标头）。还请注意，git send-email已经为您处理这种转换，并且如果您要将结果提供给该选项，则不应使用此选项git send-email。

--add-header=<header>

将任意标题添加到电子邮件标题。这是除了任何配置的标题之外，可能会多次使用。例如，--add-header="Organization: git-foo"。否定形式--no-add-header丢弃所有（To:，Cc:和自定义）标题添加到配置或命令行。

--no-cover-letter

除了这些补丁之外，还要生成一个包含分支描述，shortlog 和总体diffstat的封面文件。您可以在发送之前在文件中填写说明。

--notes=<ref>

在三条虚线后添加注释（请参阅 git-notes [1]）以进行提交。

预期的用例是编写不属于提交日志消息的提交的支持解释，并将其包含在补丁提交中。尽管可以在format-patch运行之后但在发送之前简单地编写这些解释，但将它们保留为Git便笺可让它们在补丁系列的各个版本之间维护它们（但请参阅notes.rewritegit-notes [1]中有关使用此工作流的配置选项的讨论）。

--no-signature=<signature>

为每条生成的消息添加一个签名。根据 RFC 3676，签名与身体之间由一条带“ - ”的线隔开。如果省略签名选项，则签名默认为 Git 版本号。

--signature-file=<file>

就像 - 签名（--signature）一样工作，除了从文件读取签名。

--suffix=.<sfx>

不要.patch使用指定的后缀作为生成的文件名的后缀。一个常见的选择是--suffix=.txt。将其留空将删除.patch后缀。

请注意，主角不一定是点; 例如，你可以--suffix=-patch用来获取0001-description-of-my-change-patch。

-q   --quiet

不要将生成的文件的名称打印到标准输出。

--no-binary

不要在二进制文件中输出更改的内容，而是显示这些文件已更改的通知。使用此选项生成的修补程序无法正确应用，但它们对代码审阅仍然有用。

--zero-commit

在每个修补程序的 From 头中输出全零散列，而不是提交的散列。

--base=<commit>

记录基本树信息以标识补丁系列适用的状态。有关详细信息，请参阅下面的基础树信息部分。

--root

将修订参数视为<修订范围>，即使它只是单个提交（通常会被视为<since>）。请注意，包含在指定范围内的根提交始终格式化为创建补丁，与此标志无关。

组态

您可以指定要添加到每封邮件的额外邮件标题行，主题前缀和文件后缀的默认值，输出多个修补程序时的数字修补程序，添加“To”或“Cc：”标题，配置附件以及注销修补程序带有配置变量。

[format]
        headers = "Organization: git-foo\n"
        subjectPrefix = CHANGE
        suffix = .txt
        numbered = auto
        to = <email>
        cc = <email>
        attach [ = mime-boundary-string ]
        signOff = true
        coverletter = auto

讨论

生成的补丁git format-patch是 UNIX 邮箱格式的，带有一个固定的“魔术”时间戳，表示该文件是从 format-patch 而不是真实邮箱输出的，如下所示：

From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001From: Tony Luck <tony.luck@intel.com>Date: Tue, 13 Jul 2010 11:42:54 -0700Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?= =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bit

arch/arm config files were slimmed down using a python script(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)Do the same for ia64 so we can have sleek & trim looking...

通常，它将被放置在 MUA 的草稿文件夹中，进行编辑以便及时添加评论，这些评论不应在三条破折号后进入更改日志中，然后作为消息发送，在我们的示例中，其主体以“arch / arm配置文件开头...”。在接收端，读者可以在 UNIX 邮箱中保存有趣的补丁，并将其应用于git-am [1]。

当补丁是正在进行的讨论的一部分时，git format-patch可以调整补丁生成的补丁以利用该git am --scissors特性。在对讨论作出回应后，会出现一行仅包含“ -- >8 --”（剪刀和穿孔）的行，然后是带有不必要的标题字段的修补程序：

...> So we should do such-and-such.Makes sense to me.  How about this patch?-- >8 --Subject: [IA64] Put ia64 config files on the Uwe Kleine-K��nig diet

arch/arm config files were slimmed down using a python script...

以这种方式发送补丁程序时，通常您会发送自己的补丁程序，因此除了“ From $SHA1 $magic_timestamp”标记之外，您应该省略From:并Date:从补丁程序文件中直接输入。补丁标题可能与补丁所回应的讨论主题不同，因此您可能希望保留Subject：行，如上例所示。

检查修补程序损坏

许多邮件程序如果设置不当会破坏空白。这里有两种常见的腐败类型：

• 没有any空格的空上下文行。

• 非空的上下文行在开始处有一个额外的空白字符。

测试 MUA 是否正确设置的一种方法是：

• 将修补程序发送给您自己，完全按照您的方式发送，除了To：和Cc：行不包含列表和维护者地址。

• 以 UNIX 邮箱格式将该修补程序保存到文件中。说它称为a.patch。

• 应用它：$ git fetch <project> master：test-apply $ git checkout test-apply $ git reset --hard $ git am a.patch

如果不正确应用，可能有各种原因。

• 补丁本身并不适用。这bad与你的 MUA 没有多大关系。在这种情况下重新生成之前，您可能需要使用 git-rebase [1]重新绑定修补程序。

• MUA 破坏了你的补丁; “我”会抱怨补丁不适用。查看 .git / rebase-apply /子目录，查看patch包含的文件，并检查上面提到的常见损坏模式。

• 在它的同时，检查info和final-commit文件。如果final-commit进入的内容与提交日志消息中不完全相同，接收者很可能在应用您的补丁时最终手动编辑日志消息。诸如“你好，这是我的第一个补丁。”补丁电子邮件中的\ n应该出现在表示提交消息结束的三点划线之后。

Mua 特有的提示

以下是有关如何使用各种邮件程序成功提交内联补丁的一些提示。

GMail

GMail 没有任何方法可以关闭网络界面中的换行功能，因此它会破坏您发送的任何电子邮件。然而，您可以使用“git send-email”并通过 GMail SMTP 服务器发送补丁，或者使用任何 IMAP 电子邮件客户端连接到谷歌 IMAP 服务器并通过它转发电子邮件。

有关使用git send-email通过 GMail SMTP 服务器发送补丁的提示，请参阅 git-send-email [1]的示例部分。

有关使用 IMAP 界面提交的提示，请参阅 git-imap-send [1]的示例部分。

雷鸟（Thunderbird）

默认情况下，Thunderbird 既会封装电子邮件，也会将它们标记为存在format=flowed，这两者都会使得由 Git 导致的电子邮件无法使用。

有三种不同的方法：使用附件关闭换行，将 Thunderbird 配置为不破坏修补程序，或使用外部编辑器阻止 Thunderbird 修补修补程序。

方法＃1（附加）

安装可从 https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ 获得的切换单词封套加载项。它在作曲家的“选项”菜单中添加菜单项“启用 Word 封套”你可以打勾。现在，您可以按照其他方式撰写邮件（剪切+粘贴，git format-patch| git imap-send等），但必须在键入的任何文本中手动插入换行符。

方法＃2（配置）

三个步骤：

1. 将您的邮件服务器组合配置为纯文本：编辑...帐户设置...组合和地址，取消选中“用 HTML 编写邮件”。

2. 配置你的一般合成窗口不要换行。在 Thunderbird 2：Edit..Preferences..Composition中，在Thunderbird 3：Edit..Preferences..Advanced..Config Editor 中将纯文本消息包装为0。搜索“mail.wrap_long_lines”。切换它以确保它已设置为false。此外，搜索“mailnews.wraplength”并将值设置为0。

3. 禁用使用 format = flowed：Edit..Preferences..Advanced..Config Editor。搜索“mailnews.send_plaintext_flowed”。切换它以确保它已设置为false。

完成之后，您应该能够编写电子邮件，否则会（剪切+粘贴，git format-patch| git imap-send等），并且修补程序不会被损坏。

方法＃3（外部编辑器）

需要以下Thunderbird扩展：http ://aboutconfig.mozdev.org/的AboutConfig 和http://globs.org/articles.php?lng=en&pg=8的外部编辑器

1. 使用您选择的方法将补丁作为文本文件准备。

2. 在打开撰写窗口之前，使用编辑→帐户设置取消选中用于发送补丁的帐户的“撰写和寻址”面板中的“以 HTML 格式撰写邮件”设置。

3. 在主 Thunderbird 窗口中，before打开修补程序的撰写窗口，使用工具→about：config 将以下内容设置为指示值：mailnews.send_plaintext_flowed => false mailnews.wraplength => 0

4. 打开撰写窗口并单击外部编辑器图标。

5. 在外部编辑器窗口中，读入补丁文件并正常退出编辑器。

注意：可以使用 about：config 和以下设置执行第2步，但尚未尝试过。

        mail.html_compose                       => false
        mail.identity.default.compose_html      => false
        mail.identity.id?.compose_html          => false

在 contrib / thunderbird-patch-inline中有一个脚本，它可以帮助您以简单的方式在 Thunderbird 中包含修补程序。要使用它，请执行上述步骤，然后使用脚本作为外部编辑器。

KMail

这应该可以帮助您使用 KMail 内联提交补丁。

1. 准备修补程序作为文本文件。

2. 点击新邮件。

3. 在 Composer 窗口中的“选项”下面，确保没有设置“自动换行”。

4. 使用消息→插入文件...并插入修补程序。

5. 返回撰写窗口：在邮件中添加您希望的任何其他文本，填写地址和主题字段，然后按发送。

基础树信息

基本树信息块用于维护人员或第三方测试人员了解修补程序系列适用的确切状态。它包括的base commit，这是一个众所周知的承诺即是该项目历史上其他人的稳定部分的一部分工作过的，零个或多个prerequisite patches，这是众所周知的补丁在飞行中是没有的又一部分base commit是需要base commit在补丁应用之前以拓扑顺序应用。

在base commit被示为“基提交：”，后跟提交对象名称的40进制。prerequisite patch显示为“prerequisite-patch-id：”，后跟40-hex patch id，可通过将git patch-id --stable命令传递给补丁来获得。

想象一下，在公共提交 P 的基础上，你从其他人那里应用了众所周知的补丁 X，Y 和 Z，然后构建了你的三个补丁系列 A，B，C，历史将会是这样的：

---P---X---Y---Z---A---B---C

使用git format-patch --base=P -3 C（或其变体，例如使用--cover-letter或使用Z..C而不是-3 C指定范围），基本树信息块显示在命令输出的第一条消息（第一个补丁或封面信函）的末尾，如下所示：

base-commit: P
prerequisite-patch-id: X
prerequisite-patch-id: Y
prerequisite-patch-id: Z

对于非线性拓扑，如

---P---X---A---M---C
    \         /
     Y---Z---B

您也可以使用git format-patch --base=P -3 C为 A，B 和 C 生成补丁，P，X，Y，Z的标识符将附加在第一条消息的末尾。

如果--base=auto在 cmdline 中设置，它将自动跟踪基本提交，基本提交将成为远程跟踪分支的提交提交和 cmdline 中指定的修订范围的合并基础。对于本地分支，您需要git branch --set-upstream-to在使用此选项之前跟踪远程分支。

示例

• 提取修订 R1 和 R2 之间的提交，然后将它们应用到当前分支的顶部，并用git am樱桃选择它们：$ git format-patch -k --stdout R1..R2 | git am -3 -k

• 提取当前分支中但不在原始分支中的所有提交：$ git format-patch origin

对于每个提交，在当前目录中创建一个单独的文件。

• 提取origin自项目开始以来的所有提交：$ git format-patch --root origin

• 与前一个相同：$ git format-patch -M -b origin

此外，它还可以检测并处理重命名并完全重写以生成重命名补丁。重命名补丁减少了文本输出量，并且通常更容易查看。请注意，非 Git“修补程序”程序不会理解重命名修补程序，所以只有当您知道收件人使用 Git 来应用修补程序时才使用它。

• 从当前分支中提取三个最高提交并将它们格式化为电子邮件补丁：$ git format-patch -3

也可以看看

git-am[1], git-send-email[1]