Git 中文参考（六）（2）

Git 中文参考（六）（1）https://developer.aliyun.com/article/1565802

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

--no-attach 

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

--inline[=<boundary>] 

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

--thread[=<style>] 

--no-thread 

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

可选的< style>参数可以是shallow或deep。 _ 浅 _ 线程使每个邮件都回复到系列的头部，其中头部是从求职信，--in-reply-to和第一个补丁邮件中按顺序选择的。 _ 深 _ 线程使每封邮件都回复上一封邮件。

除非设置了format.thread配置，否则默认值为--no-thread。如果指定--thread时没有样式，则默认为format.thread指定的样式（如果有），否则为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，主题前缀（默认情况下为“PATCH”，但可通过--subject-prefix选项配置）附加了“v< n>”。例如。 --reroll-count=4可能会生成[主题：[PATCH v4 1/20]添加 makefile“的v4-0001-add-makefile.patch文件。

--to=<email> 

将To:标头添加到电子邮件标头中。这是对任何已配置标头的补充，可以多次使用。否定形式--no-to丢弃到目前为止添加的所有To:标题（从配置或命令行）。

--cc=<email> 

将Cc:标头添加到电子邮件标头中。这是对任何已配置标头的补充，可以多次使用。否定形式--no-cc丢弃到目前为止添加的所有Cc:标题（从配置或命令行）。

--from 

--from=<ident> 

在每个提交电子邮件的From:标题中使用ident。如果提交的作者标识在文本上与提供的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 

除了补丁之外，还生成一个包含分支描述，短信和整体 diffstat 的求职信文件。您可以在发送之前在文件中填写说明。

--interdiff=<previous> 

作为审阅者辅助工具，请在封面信中插入一个 interdiff，或作为单补丁系列的单个补丁的注释，显示补丁系列的先前版本与当前正在格式化的系列之间的差异。 previous是一个单一的修订版，命名前一个系列的提示，它与正在格式化的系列共享一个共同的基础（例如git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2）。

--range-diff=<previous> 

作为评论者的帮助，将一个范围差异（参见 git-range-diff [1] ）插入到求职信中，或作为单补丁系列的单个补丁的评论，显示之间的差异补丁系列的先前版本和当前正在格式化的系列。 previous可以是命名前一系列提示的单个修订，如果它与正在格式化的系列共享一个公共基础（例如git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2），或者如果系列的两个版本不相交，则为修订范围（例如git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2）。

请注意，传递给命令的 diff 选项会影响format-patch的主要产品的生成方式，并且它们不会传递给用于生成封面信函材料的基础range-diff机器（这可能在将来发生变化）。

--creation-factor=<percent> 

与--range-diff一起使用，通过调整创建/删除成本软糖因子，调整与先前和当前系列补丁之间的提交匹配的启发式。有关详细信息，请参阅 git-range-diff [1] ）。

--notes[=<ref>] 

在三个虚线后添加注释（参见 git-notes [1] ）进行提交。

这种情况的预期用例是为不属于提交日志消息的提交编写支持说明，并将其包含在补丁提交中。虽然可以在format-patch运行之后但在发送之前简单地编写这些解释，但将它们保留为 Git 注释允许它们在补丁系列的版本之间进行维护（但请参阅 git 中notes.rewrite配置选项的讨论） -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 

将修订参数视为< revision range>，即使它只是一次提交（通常将其视为< since>）。请注意，指定范围中包含的根提交始终格式化为创建修补程序，与此标志无关。

--progress 

在生成修补程序时显示有关 stderr 的进度报告。

组态

您可以指定要添加到每封邮件的额外邮件标题行，主题前缀和文件后缀的默认值，输出多个补丁时的编号补丁，添加“收件人”或“抄送：”标题，配置附件和签署补丁配置变量。

[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 邮箱格式，带有固定的“魔术”时间戳，表示文件是从格式补丁而不是真实邮箱输出的，如下所示：

From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Tue, 13 Jul 2010 11:42:54 -0700
Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
 =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-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：行，就像上面的示例一样。

检查修补程序损坏

如果没有正确设置许多邮件程序将破坏空白。以下是两种常见的腐败类型：

• 没有 _ 任何 _ 空格的空上下文行。
  
• 非空上下文行，在开头有一个额外的空格。
  

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

• 除了使用不包含列表和维护者地址的 To：和 Cc：行之外，完全按照您的方式发送补丁。
  
• 将该修补程序保存为 UNIX 邮箱格式的文件。比如叫它 a.patch。
  
• 适用它：

$ git fetch <project> master:test-apply
$ git checkout test-apply
$ git reset --hard
$ git am a.patch

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

• 补丁本身并不干净。那是 _ 坏 _，但与你的 MUA 没什么关系。在这种情况下重新生成之前，您可能需要使用 git-rebase [1] 来修改补丁。
  
• MUA 破坏了你的补丁; “我”会抱怨补丁不适用。查看.git / rebase-apply /子目录，查看 _ 补丁 _ 文件包含的内容，并检查上面提到的常见损坏模式。
  
• 在此期间，检查 _ 信息 _ 和 _ 最终提交 _ 文件。如果 final-commit 中的内容不是您希望在提交日志消息中看到的内容，那么接收器最终可能会在应用您的修补程序时手动编辑日志消息。诸如“嗨，这是我的第一个补丁。\ n”在补丁电子邮件中的内容应该出现在表示提交消息结束的三个虚线之后。
  

特定于 MUA 的提示

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

GMail 的

GMail 无法在网络界面中关闭换行，因此它会破坏您发送的任何电子邮件。但是，您可以使用“git send-email”并通过 GMail  SMTP 服务器发送补丁，或使用任何 IMAP 电子邮件客户端连接到 Google IMAP 服务器并通过该服务器转发电子邮件。

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

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

雷鸟

默认情况下，Thunderbird 会将电子邮件包装起来并将其标记为 format = flowed ，这两种情况都会导致 Git 无法使用该电子邮件。

有三种不同的方法：使用附加组件来关闭换行，配置 Thunderbird 以不破坏补丁，或者使用外部编辑器来防止 Thunderbird 破坏补丁。

方法＃1（附加）

安装可从 addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ 获得的 Toggle Word Wrap 附加组件。它添加了一个菜单项“启用 Word Wrap”作曲家的“选项”菜单，您可以勾选。现在你可以像你一样编写消息（剪切+粘贴， git format-patch | git imap-send 等），但你必须在任何地方手动插入换行符您键入的文本。

方法＃2（配置）

三个步骤：

1. 将您的邮件服务器组成配置为纯文本：编辑…帐户设置…组合＆amp;寻址，取消选中“以 HTML 格式撰写邮件”。
   
2. 将常规合成窗口配置为不换行。
   在 Thunderbird 2 中：Edit…Preferences…Composition，将纯文本消息包装在 0
   在 Thunderbird 3：Edit…Preferences…Advanced…Config 编辑器。搜索“mail.wrap_long_lines”。切换它以确保它设置为false。此外，搜索“mailnews.wraplength”并将值设置为 0。
   
3. 禁用 format = flowed：Edit…Preferences…Advanced…Config Editor。搜索“mailnews.send_plaintext_flowed”。切换它以确保它设置为false。
   

完成之后，你应该能够像你一样编写电子邮件（剪切+粘贴， _git 格式补丁 _ | git imap-send 等），补丁将不被破坏。

方法＃3（外部编辑）

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

1. 使用您选择的方法将补丁准备为文本文件。
   
2. 在打开撰写窗口之前，请使用编辑→帐户设置取消选中要用于发送修补程序的帐户的“撰写和寻址”面板中的“以 HTML 格式撰写邮件”设置。
   
3. 在主要的 Thunderbird 窗口中，之前的 _ 打开补丁的撰写窗口，使用工具→about：config 将以下内容设置为指示的值：_

mailnews.send_plaintext_flowed  => false
  mailnews.wraplength             => 0

1. 打开撰写窗口，然后单击外部编辑器图标。
   
2. 在外部编辑器窗口中，读入补丁文件并正常退出编辑器。
   

附注：可以使用 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 显示为“base-commit：”，后跟提交对象名称的 40-hex。 _ 先决条件补丁 _ 显示为“prerequisite-patch-id：”，后跟 40-hex _ 补丁 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 的标识符。

如果在 cmdline 中设置--base=auto，它将自动跟踪基本提交，基本提交将是远程跟踪分支的提示提交和 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

• 对于每个提交，在当前目录中创建单独的文件。
• 从项目开始以来，提取导致 _ 起源 _ 的所有提交：

$ git format-patch --root origi

• 与前一个相同：

$ git format-patch -M -B origin

• 此外，它可以检测并处理重命名并智能地完成重写以生成重命名补丁。重命名补丁可减少文本输出量，并且通常可以更轻松地进行查看。请注意，非 Git“补丁”程序将无法理解重命名补丁，因此仅在您知道收件人使用 Git 应用补丁时才使用它。
• 从当前分支中提取三个最顶层的提交，并将它们格式化为可通过电子邮件发送的补丁：

$ git format-patch -3

也可以看看

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

GIT

部分 git [1] 套件

git-send-email

原文： git-scm.com/docs/git-send-email

名称

git-send-email - 以电子邮件形式发送补丁集合

概要

git send-email [<options>] <file|directory|rev-list options>…
git send-email --dump-aliases

描述

获取命令行上给出的补丁并通过电子邮件发送出去。可以将修补程序指定为文件，目录（将发送目录中的所有文件），或直接指定为修订列表。在最后一种情况下， git-format-patch [1] 接受的任何格式都可以传递给 git send-email。

电子邮件的标题可通过命令行选项进行配置。如果未在命令行中指定，将提示用户启用 ReadLine 接口以提供必要信息。

补丁文件有两种格式：

1. mbox 格式文件
   这就是 git-format-patch [1] 生成的内容。大多数标头和 MIME 格式都会被忽略。
   
2. Greg Kroah-Hartman 的 send_lots_of_email.pl 脚本使用的原始格式
   此格式要求文件的第一行包含“Cc：”值和消息的“Subject：”作为第二行。

Git 中文参考（六）（3）https://developer.aliyun.com/article/1565804