Git
日本語 ▾ トピック ▾ 最新バージョン ▾ git-format-patchは2.46.0で最後に更新されました

名前

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] [--always]
		   [--cover-from-description=<mode>]
		   [--rfc[=<rfc>]] [--subject-prefix=<subject-prefix>]
		   [(--reroll-count|-v) <n>]
		   [--to=<email>] [--cc=<email>]
		   [--[no-]cover-letter] [--quiet]
		   [--[no-]encode-email-headers]
		   [--no-notes | --notes[=<ref>]]
		   [--interdiff=<previous>]
		   [--range-diff=<previous> [--creation-factor=<percent>]]
		   [--filename-max-length=<n>]
		   [--progress]
		   [<common-diff-options>]
		   [ <since> | <revision-range> ]

説明

マージコミット以外の各コミットを、コミットごとに1つの「メッセージ」に「パッチ」として準備し、UNIXメールボックスに似た形式にフォーマットします。このコマンドの出力は、メール送信や *git am* での使用に便利です。

コマンドによって生成される「メッセージ」は3つの部分で構成されます。

  • `From <commit>` で始まり、固定の `Mon Sep 17 00:00:00 2001` という日付スタンプを持つ短いメタデータヘッダー。「file(1)」のようなプログラムがこのファイルが本コマンドの出力であることを認識するのに役立ちます。作成者情報、作成日時、変更のタイトル（コミットログメッセージの最初の段落から取得）を記録するフィールド。

  • コミットログメッセージの2段落目以降。

  • コミットとその親の間の「diff -p --stat」出力（git-diff[1] 参照）である「パッチ」。

ログメッセージとパッチは、3つのダッシュで構成される行で区切られます。

操作対象のコミットを指定するには、2つの方法があります。

  1. 単一のコミット <since> は、現在のブランチの先頭に至るコミットのうち、<since> に至る履歴に含まれていないコミットを出力することを指定します。

  2. 汎用 <revision-range> 式（gitrevisions[7] の「リビジョンの指定」セクションを参照）は、指定された範囲内のコミットを意味します。

単一の<commit>の場合、最初のルールが優先されます。2番目のルール、つまり履歴の最初から<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` ヘッダーを生成し、2番目以降のパッチメールが最初のメールへの返信として表示されるようにします。これはまた、参照するための `Message-ID` ヘッダーも生成します。

オプション

-p
--no-stat

diffstatのないプレーンなパッチを生成します。

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

通常の3行ではなく、<n>行のコンテキストを持つ差分を生成します。

--output=<file>

標準出力ではなく、特定のファイルに出力します。

--output-indicator-new=<char>
--output-indicator-old=<char>
--output-indicator-context=<char>

生成されたパッチで、新しい行、古い行、またはコンテキスト行を示すために使用される文字を指定します。通常はそれぞれ *+*、 *-*, ' ' です。

--indent-heuristic

パッチを読みやすくするために差分ハンクの境界をシフトするヒューリスティックを有効にします。これはデフォルトです。

--no-indent-heuristic

インデントヒューリスティックを無効にします。

--minimal

可能な限り最小の差分が生成されるように、追加の時間を費やします。

--patience

「patience diff」アルゴリズムを使用して差分を生成します。

--histogram

「histogram diff」アルゴリズムを使用して差分を生成します。

--anchored=<text>

「anchored diff」アルゴリズムを使用して差分を生成します。

このオプションは複数回指定できます。

ソースとデスティネーションの両方に存在する行が1つだけ存在し、このテキストで始まる場合、このアルゴリズムは、出力で削除または追加として表示されないようにしようとします。内部的には「patience diff」アルゴリズムを使用します。

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

差分アルゴリズムを選択します。バリアントは以下のとおりです。

`default`, `myers`

基本的な貪欲差分アルゴリズム。現在、これはデフォルトです。

`minimal`

可能な限り最小の差分が生成されるように、追加の時間を費やします。

`patience`

パッチ生成時に「patience diff」アルゴリズムを使用します。

`histogram`

このアルゴリズムは、patienceアルゴリズムを拡張して「低頻度の共通要素をサポート」します。

たとえば、 `diff.algorithm` 変数をデフォルト以外の値に設定し、デフォルト値を使用する場合、 `--diff-algorithm=default` オプションを使用する必要があります。

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

diffstat を生成します。 デフォルトでは、ファイル名部分に必要なだけのスペースが使用され、残りのスペースがグラフ部分に使用されます。 最大幅はデフォルトで端末の幅になり、端末に接続されていない場合は80列になります。これは <width> で上書きできます。 ファイル名部分の幅は、カンマの後に別の幅 <name-width> を指定するか、diff.statNameWidth=<width> を設定することで制限できます。 グラフ部分の幅は、--stat-graph-width=<width> を使用するか、diff.statGraphWidth=<width> を設定することで制限できます。 --stat または --stat-graph-width を使用すると、統計グラフを生成するすべてのコマンドに影響しますが、diff.statNameWidth または diff.statGraphWidth を設定しても git format-patch には影響しません。 3番目のパラメータ <count> を指定すると、出力を最初の <count> 行に制限し、それ以上ある場合は ... が続きます。

これらのパラメータは、--stat-width=<width>、--stat-name-width=<name-width>、および --stat-count=<count> を使用して個別に設定することもできます。

--compact-summary

ファイルの作成や削除（"new" または "gone"、シンボリックリンクの場合はオプションで "+l"）、モードの変更（実行可能ビットの追加または削除の場合はそれぞれ "+x" または "-x"）などの拡張ヘッダー情報の要約を diffstat に出力します。 情報はファイル名部分とグラフ部分の間に配置されます。 --stat を暗黙的に指定します。

--numstat

--stat と似ていますが、追加および削除された行数を10進表記で、パス名を省略せずに表示するため、機械で処理しやすくなっています。 バイナリファイルの場合、0 0 と言う代わりに 2 つの - を出力します。

--shortstat

変更されたファイルの総数と、追加および削除された行数を含む --stat 形式の最後の行のみを出力します。

-X[<param1,param2,…​>]
--dirstat[=<param1,param2,…​>]

各サブディレクトリの相対的な変更量の分布を出力します。 --dirstat の動作は、カンマ区切りのパラメータリストを渡すことでカスタマイズできます。 デフォルトは diff.dirstat 設定変数によって制御されます（git-config[1] を参照）。 使用可能なパラメータは次のとおりです。

changes

ソースから削除された行、または宛先に追加された行をカウントすることにより、dirstat の数値を計算します。 これにより、ファイル内での純粋なコードの移動量は無視されます。 つまり、ファイル内の行の並べ替えは、他の変更ほど多くカウントされません。 これは、パラメータが指定されていない場合のデフォルトの動作です。

lines

通常の行ベースの差分分析を実行し、削除/追加された行数を合計することにより、dirstat の数値を計算します。 （バイナリファイルの場合、バイナリファイルには行の自然な概念がないため、代わりに64バイトのチャンクをカウントします）。 これは、changes の動作よりも負荷の高い --dirstat 動作ですが、ファイル内の並べ替えられた行を他の変更と同じくらいカウントします。 結果の出力は、他の --*stat オプションから得られる出力と一致しています。

files

変更されたファイルの数をカウントすることにより、dirstat の数値を計算します。 変更された各ファイルは、dirstat 分析で均等にカウントされます。 これは、ファイルの内容をまったく調べる必要がないため、計算コストが最も低い --dirstat 動作です。

cumulative

子ディレクトリの変更を親ディレクトリにもカウントします。 cumulative を使用すると、報告されるパーセンテージの合計が100％を超える場合があることに注意してください。 デフォルトの（非累積）動作は、noncumulative パラメータで指定できます。

<limit>

整数パラメータは、カットオフパーセント（デフォルトでは3％）を指定します。 変更のこのパーセンテージ未満に寄与するディレクトリは、出力に表示されません。

例：以下は、変更されたファイルの総数の10％未満のディレクトリを無視し、親ディレクトリに子ディレクトリカウントを累積しながら、変更されたファイルをカウントします。--dirstat=files,10,cumulative.

--cumulative

--dirstat=cumulative の同義語

--dirstat-by-file[=<param1,param2>…​]

--dirstat=files,<param1>,<param2>…​ の同義語

--summary

作成、名前変更、モード変更などの拡張ヘッダー情報の要約を出力します。

--no-renames

構成ファイルでデフォルトで有効になっている場合でも、名前変更の検出を無効にします。

--[no-]rename-empty

空の blob を名前変更のソースとして使用するかどうかの設定です。

--full-index

パッチ形式の出力を生成するときに、最初の数文字の代わりに、"index" 行に pre-image と post-image の blob オブジェクト名を完全な形で表示します。

--binary

--full-index に加えて、git-apply で適用できるバイナリ差分を出力します。

--abbrev[=<n>]

diff-raw 形式の出力と diff-tree ヘッダー行に40バイトの16進数のオブジェクト名全体を表示する代わりに、オブジェクトを一意に参照する少なくとも <n> 桁の16進数の最短のプレフィックスを表示します。 diff-patch 出力形式では、--full-index が優先されます。つまり、--full-index が指定されている場合、--abbrev に関係なく、完全な blob 名が表示されます。 デフォルト以外の桁数は --abbrev=<n> で指定できます。

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

完全な書き換えの変更を削除と作成のペアに分割します。 これには2つの目的があります。

ファイルの完全な書き換えとなる変更を、コンテキストとしてテキストで一致する数行が混在する一連の削除と挿入としてではなく、古いものの単一の削除と新しいものの単一の挿入として扱う方法に影響します。 数字 m は -B オプションのこの側面を制御します（デフォルトは60％）。 -B/70% は、Git が完全な書き換えと見なすには、元の30％未満が結果に残っている必要があることを指定します（つまり、そうでない場合、結果のパッチはコンテキスト行が混在する一連の削除と挿入になります）。

-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

削除の preimage を省略します。つまり、ヘッダーのみを出力し、preimage と /dev/null の間の差分は出力しません。 結果のパッチは、patch または git apply で適用することを意図したものではありません。これは、変更後のテキストのレビューに集中したい人のためのものです。 さらに、出力には、そのようなパッチを手動で逆方向に適用するのに十分な情報が明らかに欠けているため、オプションの名前が付けられています。

-B と共に使用すると、削除/作成ペアの削除部分の preimage も省略されます。

-l<num>

-M および -C オプションには、名前変更/コピーのサブセットを安価に検出できるいくつかの予備手順が含まれており、その後、残りのすべてのペアになっていない宛先をすべての関連ソースと比較する網羅的なフォールバック部分が続きます。 （名前変更の場合、残りのペアになっていないソースのみが関連します。コピーの場合、すべての元のソースが関連します。）N個のソースと宛先の場合、この網羅的なチェックは O(N^2) です。 このオプションは、関係するソース/宛先ファイルの数が指定された数を超えた場合、名前変更/コピー検出の網羅的部分が実行されないようにします。 デフォルトは diff.renameLimit です。 値 0 は無制限として扱われます。

-O<orderfile>

出力にファイルが表示される順序を制御します。 これは、diff.orderFile 設定変数をオーバーライドします（git-config[1] を参照）。 diff.orderFile をキャンセルするには、-O/dev/null を使用します。

出力順序は、<orderfile> 内のグロブパターンの順序によって決定されます。 最初のパターンに一致するパス名を持つすべてのファイルが最初に出力され、2番目のパターンに一致する（ただし最初のパターンには一致しない）パス名を持つすべてのファイルが次に出力される、などとなります。 いずれのパターンにも一致しないパス名を持つすべてのファイルは、ファイルの最後に暗黙的な一致するすべてのパターンがあるかのように、最後に出力されます。 複数のパス名が同じランクを持つ場合（同じパターンに一致するが、それ以前のパターンには一致しない場合）、互いに対する出力順序は通常の順序になります。

<orderfile> は次のように解析されます。

  • 空白行は無視されるため、読みやすくするために区切り文字として使用できます。

  • ハッシュ（"#"）で始まる行は無視されるため、コメントとして使用できます。パターンがハッシュで始まる場合は、パターンの先頭にバックスラッシュ（"\"）を追加します。

  • その他の各行には、単一のパターンが含まれています。

パターンは、FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパターンと同じ構文とセマンティクスを持ちます。ただし、パス名の最後のコンポーネントを任意の数だけ削除したものがパターンと一致する場合、パス名もパターンと一致します。たとえば、パターン "foo*bar" は "fooasdfbar" および "foo/bar/baz/asdf" と一致しますが、"foobarx" とは一致しません。

--skip-to=<file>
--rotate-to=<file>

指定された <file> より前のファイルを、出力から破棄します（つまり、*スキップ*します）。または、出力の最後に移動します（つまり、*回転*します）。これらのオプションは、主に git difftool コマンドで使用するために考案されたものであり、それ以外ではあまり役に立たない可能性があります。

--relative[=<path>]
--no-relative

プロジェクトのサブディレクトリから実行する場合、このオプションを使用して、ディレクトリ外の変更を除外し、パス名をディレクトリからの相対パスで表示するように指定できます。サブディレクトリにいない場合（例：ベアリポジトリ）、引数として <path> を指定することで、出力の相対パスとするサブディレクトリを指定できます。 --no-relative は、diff.relative 設定オプションと以前の --relative の両方を無効にするために使用できます。

-a
--text

すべてのファイルをテキストとして扱います。

--ignore-cr-at-eol

比較を行う際に、行末のキャリッジリターンを無視します。

--ignore-space-at-eol

行末の空白の変更を無視します。

-b
--ignore-space-change

空白の量の変更を無視します。これは行末の空白を無視し、1つ以上の空白文字の他のすべてのシーケンスを同等と見なします。

-w
--ignore-all-space

行を比較するときに空白を無視します。これは、一方の行に空白があり、もう一方の行に空白がない場合でも、違いを無視します。

--ignore-blank-lines

すべての行が空白である変更を無視します。

-I<regex>
--ignore-matching-lines=<regex>

すべての行が <regex> に一致する変更を無視します。このオプションは複数回指定できます。

--inter-hunk-context=<lines>

diff hunk 間のコンテキストを、指定された行数まで表示し、互いに近い hunk を融合します。設定オプションが設定されていない場合は、diff.interHunkContext または 0 にデフォルト設定されます。

-W
--function-context

各変更のコンテキスト行として関数全体を表示します。関数名は、git diff がパッチ hunk ヘッダーを決定するのと同じ方法で決定されます（gitattributes[5] の *カスタム hunk ヘッダーの定義* を参照）。

--ext-diff

外部 diff ヘルパーの実行を許可します。gitattributes[5] で外部 diff ドライバーを設定する場合、git-log[1] などでこのオプションを使用する必要があります。

--no-ext-diff

外部 diff ドライバーを許可しません。

--textconv
--no-textconv

バイナリファイルを比較するときに、外部テキスト変換フィルターの実行を許可（または許可しない）します。詳細は gitattributes[5] を参照してください。textconv フィルターは通常一方向の変換であるため、結果の diff は人間が読むのに適していますが、適用することはできません。このため、textconv フィルターは、デフォルトでは git-diff[1] と git-log[1] に対してのみ有効になり、git-format-patch[1] や diff プルーミングコマンドに対しては有効になりません。

--ignore-submodules[=<when>]

diff 生成におけるサブモジュールの変更を無視します。<when> は、"none"、"untracked"、"dirty"、または "all"（デフォルト）です。"none" を使用すると、サブモジュールに追跡されていないファイルまたは変更されたファイルが含まれているか、HEAD がスーパープロジェクトに記録されているコミットと異なる場合に、サブモジュールが変更されたと見なされ、git-config[1] または gitmodules[5] の *ignore* オプションの設定をオーバーライドするために使用できます。"untracked" を使用すると、サブモジュールは追跡されていないコンテンツのみを含む場合はダーティとは見なされません（ただし、変更されたコンテンツのスキャンは引き続き行われます）。"dirty" を使用すると、サブモジュールの作業ツリーに対するすべての変更が無視され、スーパープロジェクトに格納されているコミットに対する変更のみが表示されます（これは 1.7.0 までの動作でした）。"all" を使用すると、サブモジュールに対するすべての変更が非表示になります。

--src-prefix=<prefix>

"a/" の代わりに、指定されたソースプレフィックスを表示します。

--dst-prefix=<prefix>

"b/" の代わりに、指定された宛先プレフィックスを表示します。

--no-prefix

ソースプレフィックスまたは宛先プレフィックスを表示しません。

--default-prefix

デフォルトのソースプレフィックスと宛先プレフィックス（"a/" と "b/"）を使用します。これは、diff.noprefix、diff.srcPrefix、diff.dstPrefix、diff.mnemonicPrefix などの設定変数をオーバーライドします（git-config(1) を参照）。

--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>

パッチの番号付けを 1 の代わりに <n> から開始します。

--numbered-files

出力ファイル名は、コミットのデフォルトの最初の行が付加されない、単純な番号シーケンスになります。

-k
--keep-subject

コミットログメッセージの最初の行から *[PATCH]* を削除/追加しません。

-s
--signoff

自分のコミッター ID を使用して、コミットメッセージに Signed-off-by トレーラーを追加します。詳細は git-commit[1] の signoff オプションを参照してください。

--stdout

コミットごとにファイルを作成する代わりに、すべてのコミットを標準出力に mbox 形式で出力します。

--attach[=<boundary>]

multipart/mixed 添付ファイルを作成します。最初の部分はコミットメッセージで、2番目の部分はパッチ自体で、Content-Disposition: attachment が付いています。

--no-attach

設定をオーバーライドして、添付ファイルの作成を無効にします。

--inline[=<boundary>]

multipart/mixed 添付ファイルを作成します。最初の部分はコミットメッセージで、2番目の部分はパッチ自体で、Content-Disposition: inline が付いています。

--thread[=<style>]
--no-thread

2 番目以降のメールが最初のメールへの返信として表示されるように、In-Reply-To および References ヘッダーの追加を制御します。また、参照する Message-ID ヘッダーの生成も制御します。

オプションの <style> 引数は、shallow または deep です。*shallow* スレッド化では、すべてのメールがシリーズの先頭への返信になります。先頭は、カバーレター、--in-reply-to、および最初のパッチメールから、この順序で選択されます。*deep* スレッド化では、すべてのメールが前のメールへの返信になります。

デフォルトは --no-thread です。ただし、format.thread 設定が設定されている場合を除きます。引数のない --thread は、--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> からは到達できないすべてのパッチを調べ、生成されるパッチと比較します。一致するパッチは無視されます。

--always

デフォルトでは変更のないコミットのパッチは省略されますが、このオプションを指定するとそれらも出力に含めます。

--cover-from-description=<mode>

カバーレターのどの部分をブランチの説明から自動的に生成するかを制御します。

<mode> が message または default の場合、カバーレターの件名はプレースホルダーテキストで、本文はブランチの説明で埋められます。設定やコマンドラインオプションが指定されていない場合のデフォルトモードです。

<mode> が subject の場合、ブランチの説明の最初の段落がカバーレターの件名になり、残りの説明が本文になります。

<mode> が auto の場合、ブランチの説明の最初の段落が100バイトを超える場合は message モード、そうでない場合は subject モードが使用されます。

<mode> が none の場合、カバーレターの件名と本文はどちらもプレースホルダーテキストで埋められます。

--description-file=<file>

カバーレターの生成に、ブランチの説明の代わりに <file> の内容を使用します。

--subject-prefix=<subject-prefix>

件名の標準的なプレフィックス [PATCH] の代わりに、 [<subject-prefix>] を使用します。パッチシリーズに名前を付けるために使用でき、--numbered オプションと組み合わせることができます。

設定変数 format.subjectPrefix を使用して、特定のリポジトリのすべてのパッチに適用する件名プレフィックスを設定することもできます。これは、複数のリポジトリのパッチを受け取るメーリングリストで、パッチを区別するために役立ちます（例えば、"PATCH my-project" のような値を使用します）。

--filename-max-length=<n>

標準の64バイトの代わりに、生成される出力ファイル名を約 <n> バイトで切り詰めます（短すぎる値は適切な長さに自動的に調整されます）。設定されていない場合は、設定変数 format.filenameMaxLength の値、または64がデフォルト値となります。

--rfc[=<rfc>]

文字列 <rfc> （デフォルトは "RFC"）を件名プレフィックスの前に追加します。件名プレフィックスのデフォルトは "PATCH" なので、デフォルトでは "RFC PATCH" になります。

RFC は "Request For Comments" を意味します。適用のためではなく、議論のために実験的なパッチを送信する際に使用します。"--rfc=WIP" は、パッチがまだ完成していないことを示すために便利な方法でもあります（"WIP" は "Work In Progress" の略です）。

特定の追加文字列に対する受信コミュニティの慣習が、件名プレフィックスの*後*に配置することである場合、文字列 *<rfc>* にダッシュ（" `-` "）を付けて、*<rfc>* 文字列の残りを件名プレフィックスに追加する必要があることを示すことができます。たとえば、`--rfc='-(WIP)'` は "PATCH (WIP)" になります。

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

シリーズをトピックの <n> 回目のイテレーションとしてマークします。出力ファイル名には `v<n>` が先頭に付加され、件名プレフィックス（デフォルトは "PATCH" ですが、 `--subject-prefix` オプションで設定可能）には ` v<n>` が追加されます。たとえば、 `--reroll-count=4` は、 "Subject: [PATCH v4 1/20] Add makefile" を含む `v4-0001-add-makefile.patch` ファイルを生成する可能性があります。<n> は整数である必要はありません（たとえば、 "--reroll-count=4.4" や "--reroll-count=4rev2" も許可されます）が、このようなreroll-countを使用する欠点は、以前のバージョンとのrange-diff / interdiffが新しいイテレーションがどのバージョンと比較されているかを正確に示さないことです。

--to=<email>

メールヘッダーに To: ヘッダーを追加します。これは設定済みのヘッダーに加えて、複数回使用できます。否定形 `--no-to` は、これまでに追加されたすべての `To:` ヘッダー（設定またはコマンドラインから）を破棄します。

--cc=<email>

メールヘッダーに Cc: ヘッダーを追加します。これは設定済みのヘッダーに加えて、複数回使用できます。否定形 `--no-cc` は、これまでに追加されたすべての `Cc:` ヘッダー（設定またはコマンドラインから）を破棄します。

--from
--from=<ident>

各コミットメールの From: ヘッダーに `ident` を使用します。コミットの作成者identが指定された `ident` とテキスト的に同一でない場合は、元の作成者とともにメッセージ本文に `From:` ヘッダーを配置します。`ident` が指定されていない場合は、コミッターidentを使用します。

このオプションは、実際にメールを送信し、送信者として自分自身を識別したいが、元の作成者を保持したい場合にのみ役立ちます（そして `git am` は本文内のヘッダーを正しく認識します）。また、 `git send-email` はすでにこの変換を処理しているため、結果を `git send-email` に渡す場合は、このオプションを使用しないでください。

--[no-]force-in-body-from

--from オプションで電子メールの送信者を指定した場合、デフォルトでは、送信者が作成者と異なる場合、コミットの実際の作成者を識別するために、コミットログメッセージの先頭に本文内 "From:" が追加されます。このオプションを使用すると、送信者と作成者の名前とアドレスが同じ場合でも、本文内 "From:" が追加されます。これは、メーリングリストソフトウェアが送信者のIDを改ざんする場合に役立ちます。設定変数 `format.forceInBodyFrom` の値がデフォルトになります。

--add-header=<header>

メールヘッダーに任意のヘッダーを追加します。これは、設定済みのヘッダーに加えて、複数回使用できます。たとえば、 `--add-header="Organization: git-foo"` のように使用します。否定形 `--no-add-header` は、設定またはコマンドラインからこれまでに追加された**すべて**の（ `To:`、 `Cc:`、およびカスタム）ヘッダーを破棄します。

--[no-]cover-letter

パッチに加えて、ブランチの説明、shortlog、および全体のdiffstatを含むカバーレターファイルを生成します。送信する前に、ファイルに説明を入力できます。

--encode-email-headers
--no-encode-email-headers

非ASCII文字を含むメールヘッダーを、そのまま出力する代わりに、 "Qエンコーディング"（RFC 2047で説明）でエンコードします。設定変数 `format.encodeEmailHeaders` の値がデフォルトになります。

--interdiff=<previous>

レビューアの支援として、カバーレターに、または1パッチシリーズの単一パッチのコメントとして、パッチシリーズの以前のバージョンと現在フォーマットされているシリーズの違いを示すinterdiffを挿入します。 `previous` は、フォーマットされているシリーズと共通のベースを共有する以前のシリーズの先端を指定する単一のリビジョンです（たとえば、 `git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2`）。

--range-diff=<previous>

レビューアの支援として、カバーレターに、または1パッチシリーズの単一パッチのコメントとして、パッチシリーズの以前のバージョンと現在フォーマットされているシリーズの違いを示すrange-diff（git-range-diff[1] 参照）を挿入します。 `previous` は、フォーマットされているシリーズと共通のベースを共有する場合、以前のシリーズの先端を指定する単一のリビジョン（たとえば、 `git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2`）、または2つのバージョンのシリーズが共通の祖先を持たない場合はリビジョン範囲（たとえば、 `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]を参照してください。

デフォルトは999です（git-range-diff[1] は60を使用します）。ユースケースは同じトピックの古いイテレーションとの比較を表示することであり、ツールは2つのパッチセット間でより多くの対応関係を見つける必要があるためです。

--notes[=<ref>]
--no-notes

3つのダッシュの行の後に、コミットのノート（git-notes[1] 参照）を追加します。

このユースケースは、コミットログメッセージ自体には属さないコミットの補足説明を記述し、パッチの送信に含めることです。 `format-patch` の実行後、送信前にこれらの説明を簡単に記述できますが、Gitノートとして保持することで、パッチシリーズのバージョン間でそれらを維持できます（ただし、このワークフローを使用するには、git-notes[1] の `notes.rewrite` 設定オプションの説明を参照してください）。

`format.notes` 設定が設定されていない限り、デフォルトは `--no-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ヘッダーに、コミットのハッシュではなく、すべてゼロのハッシュを出力します。

--[no-]base[=<commit>]

パッチシリーズが適用される状態を識別するために、ベースツリー情報を記録します。詳細は、以下の「ベースツリー情報」セクションを参照してください。<commit> が "auto" の場合、ベースコミットが自動的に選択されます。 `--no-base` オプションは、 `format.useAutoBase` 設定をオーバーライドします。

--root

リビジョン引数が単一のコミット（通常は <since> として扱われます）であっても、 <revision-range> として扱います。指定された範囲に含まれるルートコミットは、このフラグとは無関係に、常に作成パッチとしてフォーマットされることに注意してください。

--progress

パッチの生成中に、標準エラー出力に進行状況レポートを表示します。

設定

各メッセージに追加する追加のメールヘッダー行、件名のプレフィックスとファイルのサフィックスのデフォルト、複数のパッチを出力する場合のパッチの番号付け、"To:" または "Cc:" ヘッダーの追加、添付ファイルの設定、パッチ出力ディレクトリの変更、設定変数によるパッチの署名を行うことができます。

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

議論

git format-patch によって生成されるパッチは、UNIX メールボックス形式で、ファイルが実際のメールボックスではなく format-patch から出力されたことを示す固定の「マジック」タイムスタンプが付いています。以下はその例です。

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 のドラフトフォルダに配置され、変更ログに入らないタイムリーなコメントを3つのダッシュの後に追加するために編集され、本文が、この例では「arch/arm config files were…」で始まるメッセージとして送信されます。受信側では、読者は興味深いパッチを 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: 行を保持したいと思うでしょう。

パッチの破損の確認

多くのメーラーは、適切に設定されていない場合、空白を破損します。 ここでは、2つの一般的なタイプの破損を示します。

  • 空白が*ない*空のコンテキスト行。

  • 先頭に空白が1つ多い、空でないコンテキスト行。

MUA が正しく設定されているかどうかをテストする1つの方法は次のとおりです。

  • リストとメンテナのアドレスを含まない To: および Cc: 行を使用して、通常どおりにパッチを自分に送信します。

  • そのパッチを UNIX メールボックス形式のファイルに保存します。 a.patch と呼びましょう。

  • それを適用します。

    $ git fetch <project> master:test-apply
$ git switch test-apply
$ git restore --source=HEAD --staged --worktree :/
$ git am a.patch

正しく適用されない場合は、さまざまな理由が考えられます。

  • パッチ自体がクリーンに適用されない。 それは*悪い*ことですが、MUA とはあまり関係ありません。 この場合、git-rebase[1] でパッチをリベースしてから再生成することをお勧めします。

  • MUA がパッチを破損しました。 「am」は、パッチが適用されないことを訴えます。 .git/rebase-apply/ サブディレクトリを見て、*patch* ファイルに何が含まれているかを確認し、上記で言及した一般的な破損パターンを確認してください。

  • ついでに、*info* と *final-commit* ファイルも確認してください。 *final-commit* の内容がコミットログメッセージに表示したい内容とまったく同じでない場合、受信者はパッチを適用するときにログメッセージを手動で編集することになる可能性が非常に高くなります。 パッチメールの「こんにちは、これは最初のパッチです。\n」のようなものは、コミットメッセージの終わりを示す3つのダッシュの後に来るはずです。

MUA 固有のヒント

ここでは、さまざまなメーラーを使用してパッチをインラインで正常に送信する方法に関するヒントをいくつか示します。

Gmail

Gmail には Web インターフェースで 줄 바꿈をオフにする方法がないため、送信するメールがすべて壊れてしまいます。 ただし、「git send-email」を使用して Gmail SMTP サーバー経由でパッチを送信したり、IMAP メールクライアントを使用して Google IMAP サーバーに接続し、そのメールクライアント経由でメールを転送したりできます。

git send-email を使用して Gmail SMTP サーバー経由でパッチを送信する方法のヒントについては、git-send-email[1] の EXAMPLES セクションを参照してください。

IMAP インターフェースを使用した送信のヒントについては、git-imap-send[1] の EXAMPLES セクションを参照してください。

Thunderbird

デフォルトでは、Thunderbird はメールを 줄 바꿈するだけでなく、*format=flowed* としてフラグを立てるため、どちらの場合も Git で結果のメールを使用できなくなります。です。

3つの異なるアプローチがあります。アドオンを使用して 줄 바꿈をオフにする、Thunderbird がパッチを改ざんしないように設定する、または外部エディターを使用して Thunderbird がパッチを改ざんしないようにします。

アプローチ1（アドオン）

https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ から入手できる Toggle Word Wrap アドオンをインストールします。 これにより、コンポーザーの「オプション」メニューに「Enable Word Wrap」メニューエントリが追加され、チェックを外すことができます。これで、他の場合と同じようにメッセージを作成できます（切り取り + 貼り付け、 *git format-patch* | *git imap-send* など）が、入力するテキストに手動で 줄 바꿈を挿入する必要があります。

アプローチ2（設定）

3つのステップ

  1. メールサーバーの構成をプレーンテキストとして設定します：編集…アカウント設定…作成とアドレス指定、「HTML でメッセージを作成する」のチェックを外します。

  2. 一般的な作成ウィンドウが 줄 바꿈しないように設定します。

    Thunderbird 2：編集..設定..作成、プレーンテキストメッセージを 0 で 줄 바꿈

    Thunderbird 3：編集..設定..詳細設定..設定エディター。 「mail.wrap_long_lines」を検索します。 切り替えて、値が false に設定されていることを確認します。 また、「mailnews.wraplength」を検索して、値を 0 に設定します。.

  3. format=flowed の使用を無効にします：編集..設定..詳細設定..設定エディター。 「mailnews.send_plaintext_flowed」を検索します。 切り替えて、値が false に設定されていることを確認します。

それが完了したら、他の場合と同じようにメールを作成できるはずです（切り取り + 貼り付け、 *git format-patch* | *git imap-send* など）。 パッチは改ざんされません。

アプローチ3（外部エディター）

次の Thunderbird 拡張機能が必要です。https://mjg.github.io/AboutConfig/ の AboutConfig と https://globs.org/articles.php?lng=en&pg=8 の External Editor

  1. 選択した方法を使用して、パッチをテキストファイルとして準備します。

  2. 作成ウィンドウを開く前に、編集→アカウント設定を使用して、パッチの送信に使用するアカウントの「作成とアドレス指定」パネルで「HTML 形式でメッセージを作成する」設定のチェックを外します。

  3. Thunderbird メインウィンドウで、パッチの作成ウィンドウを開く*前*に、ツール→about:config を使用して、以下を指定された値に設定します。

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

  4. 作成ウィンドウを開き、外部エディターアイコンをクリックします。.

  5. 外部エディターウィンドウで、パッチファイルを読み込んで、エディターを通常どおり終了します。

補足：ステップ2は about:config と次の設定で行うことができるかもしれませんが、まだ誰も試していません。

	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. コンポーザーウィンドウの「オプション」に移動し、「줄 바꿈」が設定されていないことを確認します。

  4. メッセージ→ファイルの挿入…を使用して、パッチを挿入します。

  5. 作成ウィンドウに戻ります。メッセージにその他のテキストを追加し、アドレスと件名フィールドに入力して、送信を押します。.

ベースツリー情報

ベースツリー情報ブロックは、メンテナまたはサードパーティのテスターがパッチシリーズが適用される正確な状態を知るために使用されます。 これは、誰もが作業するプロジェクト履歴の安定した部分の一部である*ベースコミット*と、*ベースコミット*の上にトポロジカル順に適用する必要がある、まだ*ベースコミット*の一部ではない、進行中の既知のパッチである、ゼロ個以上の*前提条件パッチ*で構成されます。パッチを適用する前に。

*ベースコミット*は「base-commit:」の後にコミットオブジェクト名の40進数の16進数が続きます。 *前提条件パッチ*は「prerequisite-patch-id:」の後に40進数の16進数の*パッチID*が続きます。これは、パッチを git patch-id --stable コマンドに渡すことで取得できます。

公開コミット P の上に、他の誰かからの既知のパッチ X、Y、Z を適用し、次に3つのパッチシリーズ A、B、C を構築したと想像してください。履歴は次のようになります。

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

git format-patch --base=P -3 C（またはそのバリアント、たとえば --cover-letter を使用するか、範囲を指定するために -3 C の代わりに Z..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

    コミットごとに、現在のディレクトリに個別のファイルが作成されます。

  • プロジェクトの開始以来、*origin* につながるすべてのコミットを抽出します。

    $ git format-patch --root origin

  • 前のものと同じです。

    $ git format-patch -M -B origin

    さらに、名前変更と完全な書き換えをインテリジェントに検出して処理し、名前変更パッチを作成します。名前変更パッチはテキスト出力の量を削減し、一般的にレビューを容易にします。 Git 以外の「patch」プログラムは名前変更パッチを理解しないため、受信者が Git を使用してパッチを適用することがわかっている場合にのみ使用してください。

  • 現在のブランチから上位3つのコミットを抽出し、メール送信可能なパッチとしてフォーマットします。

    $ git format-patch -3

注意事項

format-patch は、要求された範囲の一部であっても、マージコミットを出力から省略することに注意してください。単純な「パッチ」には、受信側が同じマージコミットを再現するのに十分な情報が含まれていません。

関連項目

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

GIT

git[1] スイートの一部

scroll-to-top