git-format-patch · Git 中文參考

# git-format-patch > 原文： [https://git-scm.com/docs/git-format-patch](https://git-scm.com/docs/git-format-patch) ## 名稱 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>]] [--interdiff=<previous>] [--range-diff=<previous> [--creation-factor=<percent>]] [--progress] [<common diff options>] [ <since> | <revision range> ] ``` ## 描述每次提交時，將每個提交的補丁準備在一個文件中，格式化為類似于UNIX郵箱格式。此命令的輸出便于電子郵件提交或與 _git am_ 一起使用。有兩種方法可以指定要操作的提交。 1. 單個提交< since>，指定通往當前分支的提示的提交，這些提交不在歷史記錄中，導致< since>要輸出。 2. 通用<修訂范圍>表達式（參見 [gitrevisions [7]](https://git-scm.com/docs/gitrevisions) 中的“指定修訂”部分）表示指定范圍內的提交。在單個< 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]](https://git-scm.com/docs/git-commit) 的討論部分）。當輸出多個補丁時，主題前綴將改為“[PATCH n / m]”。要強制為單個補丁添加1/1，請使用`-n`。要忽略主題中的色塊編號，請使用`-N`。如果給出`--thread`，`git-format-patch`將生成`In-Reply-To`和`References`標題，以使第二個和后續的補丁郵件顯示為對第一個郵件的回復;這也會生成一個`Message-Id`標題來引用。 ## OPTIONS ``` -p ``` ``` --no-stat ``` 生成沒有任何diffstats的普通補丁。 ``` -U<n> ``` ``` --unified=<n> ``` 用< n>生成差異。上下文而不是通常的三行。 ``` --indent-heuristic ``` 啟用改變差異塊邊界的啟發式以使補丁更易于閱讀。這是默認值。 ``` --no-indent-heuristic ``` 禁用縮進啟發式。 ``` --minimal ``` 花些額外的時間來確保產生盡可能小的差異。 ``` --patience ``` 使用“耐心差異”算法生成差異。 ``` --histogram ``` 使用“histogram diff”算法生成diff。 ``` --anchored=<text> ``` 使用“錨定差異”算法生成差異。可以多次指定此選項。如果源和目標中都存在一行，只存在一次，并以此文本開頭，則此算法會嘗試阻止它在輸出中顯示為刪除或添加。它在內部使用“耐心差異”算法。 ``` --diff-algorithm={patience|minimal|histogram|myers} ``` 選擇差異算法。變體如下： ``` default, myers ``` 基本的貪心差異算法。目前，這是默認值。 ``` 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>`單獨設置這些參數。 ``` --compact-summary ``` 輸出擴展標題信息的精簡摘要，例如文件創建或刪除（“新”或“消失”，如果是符號鏈接，則可選“+ l”）和模式更改（“+ x”或“-x”用于添加或刪除diffstat中的可執行位）。信息放在文件名部分和圖形部分之間。意味著`--stat`。 ``` --numstat ``` 與`--stat`類似，但顯示十進制表示法中添加和刪除的行數以及沒有縮寫的路徑名，以使其更加機器友好。對于二進制文件，輸出兩個`-`而不是`0 0`。 ``` --shortstat ``` 僅輸出`--stat`格式的最后一行，其中包含已修改文件的總數，以及已添加和已刪除行的數量。 ``` --dirstat[=<param1,param2,…?>] ``` 輸出每個子目錄的相對更改量的分布。 `--dirstat`的行為可以通過以逗號分隔的參數列表傳遞來定制。默認值由`diff.dirstat`配置變量控制（參見 [git-config [1]](https://git-scm.com/docs/git-config) ）。可以使用以下參數： ``` changes ``` 通過計算已從源中刪除或添加到目標的行來計算dirstat數。這忽略了文件中純代碼移動的數量。換句話說，重新排列文件中的行不會像其他更改那樣計算。這是沒有給出參數時的默認行為。 ``` lines ``` 通過執行常規的基于行的差異分析來計算dirstat數字，并對移除/添加的行數進行求和。（對于二進制文件，計算64字節塊，因為二進制文件沒有自然的線條概念）。這是比`changes`行為更昂貴的`--dirstat`行為，但它確實計算文件中重新排列的行與其他更改一樣多。結果輸出與您從其他`--*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>][/<m>] ``` ``` --break-rewrites[=[<n>][/<m>]] ``` 將完整的重寫更改分為刪除和創建對。這有兩個目的：它影響了一個更改的方式，相當于一個文件的完全重寫，而不是一系列的刪除和插入混合在一起，只有幾行恰好與文本作為上下文匹配，而是作為單個刪除所有舊的后跟一個單個插入所有新內容，數字`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]](https://git-scm.com/docs/git-config) ）。要取消`diff.orderFile`，請使用`-O/dev/null`。輸出順序由< orderfile>中的glob模式的順序決定。首先輸出所有與第一個模式匹配的路徑名的文件，然后輸出所有與第二個模式（但不是第一個模式）匹配的路徑名的文件，依此類推。路徑名與任何模式都不匹配的所有文件都是最后輸出的，就好像文件末尾有一個隱式匹配所有模式一樣。如果多個路徑名具有相同的等級（它們匹配相同的模式但沒有早期模式），則它們相對于彼此的輸出順序是正常順序。 < orderfile>解析如下： * 空行被忽略，因此可以將它們用作分隔符以提高可讀性。 * 以哈希（“`#`”）開頭的行將被忽略，因此它們可用于注釋。如果以散列開頭，則將反斜杠（“`\`”）添加到模式的開頭。 * 每個其他行包含一個模式。模式與沒有FNM_PATHNAME標志的fnmatch（3）使用的模式具有相同的語法和語義，但如果刪除任意數量的最終路徑名組件與模式匹配，則路徑名也匹配模式。例如，模式“`foo*bar`”匹配“`fooasdfbar`”和“`foo/bar/baz/asdf`”而不匹配“`foobarx`”。 ``` -a ``` ``` --text ``` 將所有文件視為文本。 ``` --ignore-cr-at-eol ``` 進行比較時，忽略行尾的回車。 ``` --ignore-space-at-eol ``` 忽略EOL中的空白更改。 ``` -b ``` ``` --ignore-space-change ``` 忽略空格量的變化。這會忽略行尾的空格，并將一個或多個空白字符的所有其他序列視為等效。 ``` -w ``` ``` --ignore-all-space ``` 比較線條時忽略空格。即使一行有空格而另一行沒有空格，這也會忽略差異。 ``` --ignore-blank-lines ``` 忽略其行全部為空的更改。 ``` --inter-hunk-context=<lines> ``` 顯示差異之間的上下文，直到指定的行數，從而融合彼此接近的帥哥。如果未設置配置選項，則默認為`diff.interHunkContext`或0。 ``` -W ``` ``` --function-context ``` 顯示整個周圍的變化功能。 ``` --ext-diff ``` 允許執行外部diff助手。如果使用 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 設置外部差異驅動程序，則需要將此選項與 [git-log [1]](https://git-scm.com/docs/git-log) 和朋友一起使用。 ``` --no-ext-diff ``` 禁止外部差異驅動程序。 ``` --textconv ``` ``` --no-textconv ``` 在比較二進制文件時允許（或禁止）外部文本轉換過濾器運行。有關詳細信息，請參閱 [gitattributes [5]](https://git-scm.com/docs/gitattributes) 。由于textconv過濾器通常是單向轉換，因此生成的差異適合人類使用，但無法應用。因此，默認情況下，textconv過濾器僅針對 [git-diff [1]](https://git-scm.com/docs/git-diff) 和 [git-log [1]](https://git-scm.com/docs/git-log) 啟用，但不適用于 [git-format-patch [ 1]](https://git-scm.com/docs/git-format-patch) 或差異管道命令。 ``` --ignore-submodules[=<when>] ``` 忽略差異生成中子模塊的更改。 <當>可以是“none”，“untracked”，“dirty”或“all”，這是默認值。使用“none”時，如果子模塊包含未跟蹤或修改的文件，或者其HEAD與超級項目中記錄的提交不同，則可以使用“無”來修改子模塊，并可用于覆蓋[中 _ignore_ 選項的任何設置git-config [1]](https://git-scm.com/docs/git-config) 或 [gitmodules [5]](https://git-scm.com/docs/gitmodules) 。當使用“未跟蹤”時，如果子模塊僅包含未跟蹤的內容（但仍會掃描修改的內容），則子模塊不會被視為臟。使用“臟”忽略對子模塊工作樹的所有更改，僅顯示存儲在超級項目中的提交的更改（這是1.7.0之前的行為）。使用“all”隱藏子模塊的所有更改。 ``` --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]](https://git-scm.com/docs/gitdiffcore) 。 ``` -<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]](https://git-scm.com/docs/git-commit) 中的簽收選項。 ``` --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`。 _淺_線程使每個郵件都回復到系列的頭部，其中頭部是從求職信，`--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<n>`，主題前綴（默認情況下為“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]](https://git-scm.com/docs/git-range-diff) ）插入到求職信中，或作為單補丁系列的單個補丁的評論，顯示之間的差異補丁系列的先前版本和當前正在格式化的系列。 `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]](https://git-scm.com/docs/git-range-diff) ）。 ``` --notes[=<ref>] ``` 在三個虛線后添加注釋（參見 [git-notes [1]](https://git-scm.com/docs/git-notes) ）進行提交。這種情況的預期用例是為不屬于提交日志消息的提交編寫支持說明，并將其包含在補丁提交中。雖然可以在`format-patch`運行之后但在發送之前簡單地編寫這些解釋，但將它們保留為Git注釋允許它們在補丁系列的版本之間進行維護（但請參閱 [git中`notes.rewrite`配置選項的討論） -notes [1]](https://git-scm.com/docs/git-notes) 使用此工作流程）。 ``` --[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]](https://git-scm.com/docs/git-am) 。當補丁是正在進行的討論的一部分時， _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]](https://git-scm.com/docs/git-rebase) 來修改補丁。 * 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]](https://git-scm.com/docs/git-send-email) 的示例部分。有關使用IMAP界面提交的提示，請參閱 [git-imap-send [1]](https://git-scm.com/docs/git-imap-send) 的示例部分。 ### 雷鳥默認情況下，Thunderbird會將電子郵件包裝起來并將其標記為 _format = flowed_ ，這兩種情況都會導致Git無法使用該電子郵件。有三種不同的方法：使用附加組件來關閉換行，配置Thunderbird以不破壞補丁，或者使用外部編輯器來防止Thunderbird破壞補丁。 #### 方法＃1（附加）安裝可從 [https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/](https://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擴展：來自 [http://aboutconfig.mozdev.org/](http://aboutconfig.mozdev.org/) 的AboutConfig和來自[的外部編輯http://globs.org/articles.php?lng=en&pg= 8](http://globs.org/articles.php?lng=en&pg=8) 1. 使用您選擇的方法將補丁準備為文本文件。 2. 在打開撰寫窗口之前，請使用編輯→帳戶設置取消選中要用于發送修補程序的帳戶的“撰寫和尋址”面板中的“以HTML格式撰寫郵件”設置。 3. 在主要的Thunderbird窗口中，之前的_打開補丁的撰寫窗口，使用工具→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_ 顯示為“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 origin ``` * 與前一個相同： ``` $ git format-patch -M -B origin ``` 此外，它可以檢測并處理重命名并智能地完成重寫以生成重命名補丁。重命名補丁可減少文本輸出量，并且通常可以更輕松地進行查看。請注意，非Git“補丁”程序將無法理解重命名補丁，因此僅在您知道收件人使用Git應用補丁時才使用它。 * 從當前分支中提取三個最頂層的提交，并將它們格式化為可通過電子郵件發送的補丁： ``` $ git format-patch -3 ``` ## 也可以看看 [git-am [1]](https://git-scm.com/docs/git-am) ， [git-send-email [1]](https://git-scm.com/docs/git-send-email) ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件