名稱（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]中的“指定修訂”一節(jié)）意味著指定范圍內的提交。

第一條規(guī)則優(yōu)先于單個<commit>的情況。要應用第二條規(guī)則，即格式化從歷史開始直到<commit>的所有內容，請使用\--root選項：git format-patch --root <commit>。如果你只想格式化<commit>本身，你可以這樣做git format-patch -1 <commit>。

默認情況下，每個輸出文件都從1開始依次編號，并使用提交消息的第一行（按路徑名安全性）作為文件名。使用該--numbered-files選項，輸出文件名稱將僅為數(shù)字，而不會附加提交的第一行。除非--stdout指定了選項，否則輸出文件的名稱將打印到標準輸出。

如果-o指定，則輸出文件將在<dir>中創(chuàng)建。否則，它們將在當前工作目錄中創(chuàng)建。默認路徑可以使用format.outputDirectory配置選項進行設置。該-o選項優(yōu)先format.outputDirectory。要將補丁存儲在當前工作目錄中，即使在format.outputDirectory其他位置使用也是如此-o .。

默認情況下，單個補丁的主題是“PATCH”，接下來是從提交消息到第一個空行的連接（請參閱 git-commit [1]的討論部分））。

當輸出多個音色時，主題前綴將改為“PATCH n / m”。要強制為單個補丁添加1/1，請使用-n。要從主題中省略修補程序編號，請使用-N。

如果給定--thread，git-format-patch將生成In-Reply-To并References標題使第二個和后續(xù)的補丁郵件顯示為對第一個郵件的答復; 這也會生成一個Message-Id頭引用。

選項

-p   --no-stat

無需任何 diffstats 即可生成簡單的修補程序。

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

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

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

這些是為了幫助調試和調整實驗啟發(fā)式（默認情況下是關閉的），這些啟發(fā)式技術改變了差異邊界以使修補程序更易于閱讀。

--minimal

花費額外的時間來確保生成最小可能的差異。

--patience

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

--histogram

使用“直方圖差異”算法生成差異。

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

選擇一種差異算法。變體如下：

default, myers

基本的貪婪 diff 算法。目前，這是默認設置。

minimal

花費額外的時間來確保生成最小可能的差異。

patience

生成補丁時使用“耐心差異”算法。

histogram

該算法將耐心算法擴展為“支持低出現(xiàn)率的通用元素”。

例如，如果您將 diff.algorithm 變量配置為非默認值并且想要使用默認值，那么您必須使用--diff-algorithm=default選項。

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

生成一個 diffstat。默認情況下，文件名部分使用盡可能多的空間，其余部分使用圖形部分。最大寬度默認為終端寬度，如果未連接到終端，則最大寬度為80列，并且可以被覆蓋<width>。文件名部分的寬度可以通過<name-width>逗號后面的另一個寬度來限制。圖形部分的寬度可以通過使用--stat-graph-width=<width>（影響所有生成統(tǒng)計圖的命令）或通過設置diff.statGraphWidth=<width>（不影響git format-patch）來限制。通過給出第三個參數(shù)<count>，可以將輸出限制在第一<count>行，...如果還有更多的話。

這些參數(shù)也可以單獨設置--stat-width=<width>，--stat-name-width=<name-width>和--stat-count=<count>。

--numstat

類似于--stat，但顯示十進制表示法中添加和刪除的行數(shù)以及不帶縮寫的路徑名，以使其更加機器友好。對于二進制文件，輸出兩個-而不是說0 0。

--shortstat

只輸出--stat包含修改文件總數(shù)的格式的最后一行，以及添加和刪除行的數(shù)量。

--dirstat=<param1,param2,…>

輸出每個子目錄的相對變化量分布。--dirstat可以通過傳遞逗號分隔的參數(shù)列表來定制行為。默認值由diff.dirstat配置變量控制（請參閱 git-config [1]）。以下參數(shù)可用：

changes

通過計算已從源中刪除或添加到目標的行來計算 dirstat 數(shù)字。這會忽略文件中純代碼移動的數(shù)量。換句話說，重新排列文件中的行數(shù)不會與其他更改一樣多。這是沒有給出參數(shù)時的默認行為。

lines

通過執(zhí)行常規(guī)基于行的差異分析來計算dirstat數(shù)字，并將刪除/添加的行數(shù)相加。（對于二進制文件，取而代之的是計算64字節(jié)的塊，因為二進制文件沒有自然的行概念）。這是一種--dirstat比changes行為更為昂貴的行為，但它可以像其他更改一樣計算文件中重新排列的行數(shù)。結果輸出與您從其他--*stat選項中獲得的結果一致。

files

通過計算更改的文件數(shù)量來計算 dirstat 數(shù)字。 dirstat 分析中每個更改的文件都相同。這是計算上最便宜的--dirstat行為，因為它不必查看文件內容。

cumulative

計數(shù)父目錄的子目錄中的更改。請注意，使用時cumulative，報告的百分比總和可能超過100％。默認（非累積）行為可以用noncumulative參數(shù)指定。

<limit>

整數(shù)參數(shù)指定截斷百分比（默認為3％）。輸出中不顯示貢獻小于此百分比的目錄。

示例：以下內容將計數(shù)已更改的文件，同時忽略占已更改文件總數(shù)少于10％的目錄，并累積父目錄中的子目錄計數(shù)：--dirstat=files,10,cumulative。

--summary

輸出擴展頭信息的精簡摘要，如創(chuàng)建，重命名和模式更改。

--no-renames

關閉重命名檢測，即使配置文件提供了默認設置。

--full-index

在生成補丁格式輸出時，在“索引”行上顯示完整的映像前和映像后 blob 對象名稱，而不是第一批字符。

--binary

除了--full-index輸出可以應用的二進制差異git-apply。

--abbrev=<n>

不是在 diff-raw 格式輸出和 diff-tree 標題行中顯示完整的40字節(jié)十六進制對象名稱，只顯示部分前綴。這與--full-index上面的選項無關，后者控制 diff-patch 輸出格式。非默認的位數(shù)可以用指定--abbrev=<n>。

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

將完全重寫更改分解為刪除和創(chuàng)建對。這有兩個目的：

它影響到一種改變的方式，這種改變相當于整個文件的重寫，而不是像一系列刪除和插入混合在一起，只有幾行文本與上下文相匹配，但是作為一個單一的刪除舊的一切，隨后是一個單次插入所有新事物，并且數(shù)字m控制-B選項的這個方面（默認為60％）。-B/70%指定只有少于30％的原始數(shù)據應保留在Git的結果中，以便將其視為全部重寫（否則結果補丁將是一系列與上下文行混合的刪除和插入）。

與-M 一起使用時，完全重寫的文件也被認為是重命名的來源（通常-M 僅考慮作為重命名源消失的文件），并且該數(shù)字n控制著-B選項的這個方面（默認為50％）。-B20%指定添加和刪除相對于文件大小的20％或更多的更改有資格作為重命名為其他文件的可能來源。

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

檢測重命名。如果n被指定，則它是相似度指數(shù)的閾值（即與文件大小相比的添加/刪除量）。例如，-M90%如果超過90％的文件沒有改變，Git 應該考慮刪除/添加對是一個重命名。如果沒有%符號，該數(shù)字應作為分數(shù)讀取，并在其前面加小數(shù)點。即，-M5變成0.5，并且因此是相同的-M50%。同樣的，-M05也是一樣的-M5%。要將檢測限制為精確重命名，請使用-M100%。默認相似度指數(shù)為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刪除/創(chuàng)建對的刪除部分一起使用時，還要省略原像。

-l<num>

在-M和-C選項需要為O（n ^ 2）的處理時間，其中n是/復制目標潛在的重命名的數(shù)目。如果重命名/復制目標的數(shù)量超過指定的數(shù)量，則此選項可防止重命名/復制檢測運行。

-O<orderfile>

控制文件在輸出中出現(xiàn)的順序。這覆蓋了diff.orderFile配置變量（請參閱git-config [1]）。取消diff.orderFile，使用-O/dev/null。

輸出順序由<orderfile>中的全局模式順序決定。所有具有與第一個模式相匹配的路徑名的文件將首先輸出，接下來將輸出所有具有匹配第二個模式（但不是第一個）的路徑名的文件，依此類推。最后輸出所有不匹配任何模式的路徑名的文件，就好像文件末尾有一個隱含的匹配模式一樣。如果多個路徑名具有相同的排名（它們匹配相同的模式但沒有更早的模式），則它們的輸出順序相對于彼此是正常順序。

按以下方式解析<orderfile>：

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

• 以散列（“ #”）開頭的行會被忽略，因此它們可以用于注釋。\如果以散列開頭，則在模式的開頭添加反斜杠（“ ”）。

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

模式與沒有 FNM_PATHNAME 標志的 fnmantch（3）使用的模式具有相同的語法和語義，但如果刪除任何數(shù)量的最終路徑名組件都與模式匹配，則路徑名也與模式匹配。例如，模式“ 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 之間的上下文，直到指定的行數(shù)，從而融合彼此接近的 hunk。diff.interHunkContext如果配置選項未設置，則默認為0或0。

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

顯示整個周圍的變化功能。

--ext-diff

允許執(zhí)行一個外部比較助手。如果你用 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”中的現(xiàn)有空文件和“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

輸出文件名將是一個簡單的數(shù)字序列，不需要追加提交的默認第一行。

-k   --keep-subject

不要[PATCH]從提交日志消息的第一行剝離/添加。

-s   --signoff

使用自己的提交者身份將Signed-off-by:行添加到提交消息中。有關更多信息，請參閱git-commit [1]中的signoff選項。

--stdout

以 mbox 格式打印所有提交到標準輸出，而不是為每個文件創(chuàng)建一個文件。

--attach=<boundary>

創(chuàng)建多部分/混合附件，第一部分是第二部分中的提交消息和補丁本身Content-Disposition: attachment。

--no-attach

禁用創(chuàng)建附件，覆蓋配置設置。

--inline=<boundary>

創(chuàng)建多部分/混合附件，第一部分是第二部分中的提交消息和補丁本身Content-Disposition: inline。

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

控制添加In-Reply-To和References標題以使第二個和后續(xù)郵件顯示為對第一個的回復。還控制生成Message-Id頭引用。

可選的<style>參數(shù)可以是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 意思是“征求意見”; 在發(fā)送實驗性補丁以供討論而不是應用時使用它。

-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給出，請使用提交者標識。

請注意，此選項僅在您實際發(fā)送電子郵件并希望將自己標識為發(fā)件人時有用，但保留原作者（并且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的封面文件。您可以在發(fā)送之前在文件中填寫說明。

--notes=<ref>

在三條虛線后添加注釋（請參閱 git-notes [1]）以進行提交。

預期的用例是編寫不屬于提交日志消息的提交的支持解釋，并將其包含在補丁提交中。盡管可以在format-patch運行之后但在發(fā)送之前簡單地編寫這些解釋，但將它們保留為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>

記錄基本樹信息以標識補丁系列適用的狀態(tài)。有關詳細信息，請參閱下面的基礎樹信息部分。

--root

將修訂參數(shù)視為<修訂范圍>，即使它只是單個提交（通常會被視為<since>）。請注意，包含在指定范圍內的根提交始終格式化為創(chuàng)建補丁，與此標志無關。

組態(tài)

您可以指定要添加到每封郵件的額外郵件標題行，主題前綴和文件后綴的默認值，輸出多個修補程序時的數(shù)字修補程序，添加“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 的草稿文件夾中，進行編輯以便及時添加評論，這些評論不應在三條破折號后進入更改日志中，然后作為消息發(fā)送，在我們的示例中，其主體以“arch / arm配置文件開頭...”。在接收端，讀者可以在 UNIX 郵箱中保存有趣的補丁，并將其應用于git-am [1]。

當補丁是正在進行的討論的一部分時，git format-patch可以調整補丁生成的補丁以利用該git am --scissors特性。在對討論作出回應后，會出現(xiàn)一行僅包含“ -- >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...

以這種方式發(fā)送補丁程序時，通常您會發(fā)送自己的補丁程序，因此除了“ From $SHA1 $magic_timestamp”標記之外，您應該省略From:并Date:從補丁程序文件中直接輸入。補丁標題可能與補丁所回應的討論主題不同，因此您可能希望保留Subject：行，如上例所示。

檢查修補程序損壞

許多郵件程序如果設置不當會破壞空白。這里有兩種常見的腐敗類型：

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

• 非空的上下文行在開始處有一個額外的空白字符。

測試 MUA 是否正確設置的一種方法是：

• 將修補程序發(fā)送給您自己，完全按照您的方式發(fā)送，除了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應該出現(xiàn)在表示提交消息結束的三點劃線之后。

Mua 特有的提示

以下是有關如何使用各種郵件程序成功提交內聯(lián)補丁的一些提示。

GMail

GMail 沒有任何方法可以關閉網絡界面中的換行功能，因此它會破壞您發(fā)送的任何電子郵件。然而，您可以使用“git send-email”并通過 GMail SMTP 服務器發(fā)送補丁，或者使用任何 IMAP 電子郵件客戶端連接到谷歌 IMAP 服務器并通過它轉發(fā)電子郵件。

有關使用git send-email通過 GMail SMTP 服務器發(fā)送補丁的提示，請參閱 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 封套”你可以打勾?，F(xiàn)在，您可以按照其他方式撰寫郵件（剪切+粘貼，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. 在打開撰寫窗口之前，使用編輯→帳戶設置取消選中用于發(fā)送補丁的帳戶的“撰寫和尋址”面板中的“以 HTML 格式撰寫郵件”設置。

3. 在主 Thunderbird 窗口中，before打開修補程序的撰寫窗口，使用工具→about：config 將以下內容設置為指示值：mailnews.send_plaintext_flowed => false mailnews.wraplength => 0

4. 打開撰寫窗口并單擊外部編輯器圖標。

5. 在外部編輯器窗口中，讀入補丁文件并正常退出編輯器。

注意：可以使用 about：config 和以下設置執(zhí)行第2步，但尚未嘗試過。

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

在 contrib / thunderbird-patch-inline中有一個腳本，它可以幫助您以簡單的方式在 Thunderbird 中包含修補程序。要使用它，請執(zhí)行上述步驟，然后使用腳本作為外部編輯器。

KMail

這應該可以幫助您使用 KMail 內聯(lián)提交補丁。

1. 準備修補程序作為文本文件。

2. 點擊新郵件。

3. 在 Composer 窗口中的“選項”下面，確保沒有設置“自動換行”。

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

5. 返回撰寫窗口：在郵件中添加您希望的任何其他文本，填寫地址和主題字段，然后按發(fā)送。

基礎樹信息

基本樹信息塊用于維護人員或第三方測試人員了解修補程序系列適用的確切狀態(tài)。它包括的base commit，這是一個眾所周知的承諾即是該項目歷史上其他人的穩(wěn)定部分的一部分工作過的，零個或多個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

對于每個提交，在當前目錄中創(chuàng)建一個單獨的文件。

• 提取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]