この属性は、パスをテキストファイルとしてマークし、改行コード変換を有効にします。一致するファイルがインデックスに追加されると、ファイルの改行コードはインデックス内で LF に正規化されます。逆に、ファイルがインデックスから作業ディレクトリにコピーされると、eol 属性、Git の設定、およびプラットフォームに応じて、改行コードが LF から CRLF に変換される場合があります (下記の eol の説明を参照)。

その他の値はすべて、text が未指定のままになっているかのように Git が動作します。

この属性は、チェックアウト時に作業ツリーで特定の改行スタイルを使用するようにパスをマークします。text または text=auto が設定されている場合にのみ効果があります (上記を参照)。ただし、eol を指定すると、text が未指定のままになっている場合、自動的に text が設定されます。

下位互換性のため、crlf 属性は次のように解釈されます。

Git は通常、ファイルの内容を変更しませんが、リポジトリ内の改行コードを LF に正規化し、オプションでファイルがチェックアウトされるときに CRLF に変換するように設定できます。

作業しているリポジトリに関係なく、作業ディレクトリで CRLF 改行コードを使用したい場合は、属性を使用せずに "core.autocrlf" 設定変数を設定できます。

これにより、テキストファイルの正規化が強制されるわけではありませんが、リポジトリに追加するテキストファイルの改行コードが追加時にLFに正規化され、リポジトリですでに正規化されているファイルは正規化されたままになることが保証されます。

共同作業者がリポジトリに追加するテキストファイルの改行コードが正規化されるようにしたい場合は、すべてのファイルに対して text 属性を "auto" に設定できます。

属性を使用すると、改行コードの変換方法を細かく制御できます。以下は、Git に .txt、.vcproj、および .sh ファイルを正規化させ、.vcproj ファイルには作業ディレクトリで CRLF を、.sh ファイルには LF を強制し、.jpg ファイルは内容に関係なく正規化されないようにする例です。

クリーンな作業ディレクトリから

正規化されるべきではないファイルが git status に表示される場合は、git add -u を実行する前に text 属性を未設定にしてください。

逆に、Git が検出しないテキストファイルは、手動で正規化を有効にすることができます。

core.safecrlf が "true" または "warn" に設定されている場合、Git は現在の core.autocrlf の設定に対して変換が可逆的であるかどうかを検証します。"true" の場合、Git は不可逆な変換を拒否します。"warn" の場合、Git は警告のみを表示しますが、不可逆な変換を受け入れます。この安全機能は、作業ツリー内のファイルに対して行われるこのような変換を防ぎますが、いくつかの例外があります。たとえ…​

Git は、ASCII またはその上位セット (UTF-8、ISO-8859-1 など) でエンコードされたファイルをテキストファイルとして認識します。特定の他のエンコーディング (UTF-16 など) でエンコードされたファイルはバイナリとして解釈され、その結果、組み込みの Git テキスト処理ツール (git diff など) およびほとんどの Git Web フロントエンドは、デフォルトではこれらのファイルの内容を視覚化しません。

このような場合、working-tree-encoding 属性を使用して、作業ディレクトリ内のファイルのエンコーディングを Git に伝えることができます。この属性を持つファイルが Git に追加されると、Git は指定されたエンコーディングから UTF-8 にコンテンツを再エンコードします。最後に、Git は UTF-8 でエンコードされたコンテンツを内部データ構造 ("インデックス" と呼ばれます) に保存します。チェックアウト時には、コンテンツは指定されたエンコーディングに再エンコードされます。

working-tree-encoding 属性の使用にはいくつかの落とし穴があることに注意してください。

working-tree-encoding 属性は、ファイルを UTF-8 エンコーディングで保存できない場合、かつ Git がコンテンツをテキストとして処理できるようにしたい場合にのみ使用してください。

例として、*.ps1 ファイルがバイトオーダーマーク (BOM) 付きの UTF-16 エンコードであり、Git にプラットフォームに基づいて自動改行コード変換を実行させたい場合は、次の属性を使用します。

*.ps1 ファイルが BOM なしの UTF-16 リトルエンディアンでエンコードされており、Git に作業ディレクトリで Windows の改行コードを使用させたい場合は、次の属性を使用します (BOM 付きの UTF-16 リトルエンディアンが必要な場合は UTF-16LE の代わりに UTF-16LE-BOM を使用します)。working-tree-encoding 属性を使用する場合は、曖昧さを避けるために eol で改行コードを明示的に定義することを強くお勧めします。

使用可能なすべてのエンコーディングのリストは、以下のコマンドでプラットフォーム上で取得できます。

ファイルのエンコーディングがわからない場合は、file コマンドを使用してエンコーディングを推測できます。

パスに対して属性 ident が設定されている場合、Git はチェックアウト時に BLOB オブジェクト内の $Id$ を $Id:、その後に 40 文字の 16 進数 BLOB オブジェクト名、その後にドル記号 $ に置き換えます。作業ツリーファイル内の $Id: で始まり $ で終わるバイトシーケンスは、チェックイン時に $Id$ に置き換えられます。

filter 属性は、構成で指定されたフィルタードライバーの名前である文字列値に設定できます。

フィルタードライバは、clean コマンドと smudge コマンドで構成され、いずれも未指定にできます。チェックアウト時、smudge コマンドが指定されている場合、コマンドは標準入力から BLOB オブジェクトを受け取り、その標準出力が作業ツリーファイルの更新に使用されます。同様に、clean コマンドはチェックイン時に作業ツリーファイルの内容を変換するために使用されます。デフォルトでは、これらのコマンドは単一の BLOB のみを処理し、終了します。clean および/または smudge フィルターの代わりに長時間実行される process フィルターが使用される場合、Git は単一の Git コマンドの全ライフサイクルで、たとえば git add --all のように、単一のフィルターコマンド呼び出しですべての BLOB を処理できます。長時間実行される process フィルターが設定されている場合、常に設定された単一 BLOB フィルターよりも優先されます。process フィルターとの通信に使用されるプロトコルの説明については、以下のセクションを参照してください。

コンテンツフィルタリングの用途の1つは、プラットフォーム、ファイルシステム、およびユーザーにとってより便利な形式にコンテンツを整形することです。この操作モードでは、ここでのキーワードは「より便利にする」であり、「使用できないものを利用可能にする」ではありません。言い換えれば、誰かがフィルタドライバの定義を解除したり、適切なフィルタプログラムを持っていなかったとしても、プロジェクトは引き続き利用可能であるべきです。

コンテンツフィルタリングのもう1つの用途は、リポジトリで直接使用できないコンテンツ（Gitの外部に保存されている実際のコンテンツを参照するUUID、または暗号化されたコンテンツなど）を保存し、チェックアウト時に使用可能な形式に変換すること（外部コンテンツのダウンロード、または暗号化されたコンテンツの復号化など）です。

これら2つのフィルタは動作が異なり、デフォルトでは、フィルタは前者のコンテンツをより便利な形に整形するものと見なされます。設定にフィルタドライバの定義がない場合や、ゼロ以外のステータスで終了するフィルタドライバはエラーではなく、フィルタは何もせずにパススルーします。

フィルタがそれ自体では使用できないコンテンツを使用可能なコンテンツに変換することを宣言するには、filter.<driver>.required 設定変数を true に設定します。

注: クリーンフィルターが変更されるたびに、リポジトリは再正規化する必要があります: $ git add --renormalize .

たとえば、.gitattributes では、パスに filter 属性を割り当てます。

次に、.git/config に "filter.indent.clean" および "filter.indent.smudge" の設定を定義して、ソースファイルがチェックインされるとき ("clean" が実行される) とチェックアウトされるとき (コマンドが "cat" のため変更なし) に C プログラムの内容を変更するコマンドペアを指定します。

最良の結果を得るには、clean は2回実行しても出力を変更しないこと ("clean→clean" は "clean" と同等であるべき)、また複数の smudge コマンドが clean の出力を変更しないこと ("smudge→smudge→clean" は "clean" と同等であるべき) が推奨されます。以下のマージに関するセクションを参照してください。

"indent" フィルターは、この点において適切に動作します。つまり、すでに正しくインデントされている入力は変更しません。この場合、smudge フィルターがないということは、clean フィルターが自分の出力を変更せずに受け入れる "必要" があることを意味します。

保存されたコンテンツを使用可能にするためにフィルタが成功する「必要」がある場合、構成でフィルタが 必須 であることを宣言できます。

フィルタコマンドラインのシーケンス "%f" は、フィルタが処理しているファイル名に置き換えられます。フィルタはこれをキーワード置換に使用できます。例えば、

「%f」は処理中のパス名であることに注意してください。フィルタリングされているバージョンによっては、ディスク上の対応するファイルが存在しないか、内容が異なる場合があります。したがって、smudge および clean コマンドはディスク上のファイルにアクセスしようとせず、標準入力で提供されたコンテンツに対するフィルタとしてのみ機能する必要があります。

filter.<driver>.process を介してフィルターコマンド (文字列値) が定義されている場合、Git は単一の Git コマンドの全ライフサイクルで、単一のフィルター呼び出しですべての BLOB を処理できます。これは、長時間実行されるプロセスプロトコル (Documentation/technical/long-running-process-protocol.adoc で説明されています) を使用して実現されます。

Git がクリーンまたはスマッジが必要な最初のファイルに遭遇すると、フィルターを開始し、ハンドシェイクを実行します。ハンドシェイクでは、Git から送信されるウェルカムメッセージは "git-filter-client" であり、バージョン 2 のみがサポートされ、サポートされる機能は "clean"、"smudge"、"delay" です。

その後、Git はフラッシュパケットで終了する "key=value" ペアのリストを送信します。このリストには、少なくともフィルターコマンド (サポートされている機能に基づく) と、リポジトリのルートに対するフィルターするファイルのパス名が含まれます。フラッシュパケットの直後、Git は 0 個以上の pkt-line パケットに分割されたコンテンツと、コンテンツを終了するフラッシュパケットを送信します。フィルターは、コンテンツと最終的なフラッシュパケットを受信するまで、応答を送信してはならないことに注意してください。また、「key=value」ペアの「value」は「=」文字を含むことができますが、キーは「=」文字を含むことはありません。

フィルタは、フラッシュパケットで終了する "key=value" ペアのリストで応答することが期待されます。フィルタが問題なく処理できた場合、リストには "success" ステータスが含まれている必要があります。これらのパケットの直後、フィルタは 0 個以上の pkt-line パケットでコンテンツを送信し、最後にフラッシュパケットを送信することが期待されます。最後に、フラッシュパケットで終了する2番目の "key=value" ペアのリストが期待されます。フィルタは2番目のリストでステータスを変更することも、空のリストでステータスをそのまま維持することもできます。空のリストは、とにかくフラッシュパケットで終了する必要があることに注意してください。

結果のコンテンツが空の場合、フィルターは「success」ステータスとフラッシュパケットで応答し、空のコンテンツを通知することが期待されます。

フィルターがコンテンツを処理できない、または処理したくない場合は、「error」ステータスで応答することが期待されます。

フィルタが処理中にエラーを経験した場合、コンテンツが（部分的または完全に）送信された後に「error」ステータスを送信できます。

フィルタがコンテンツだけでなく、Git プロセスのライフタイム中に将来のコンテンツも処理できない、または処理したくない場合、プロトコルの任意の時点で「abort」ステータスで応答することが期待されます。

Git は "error"/"abort" ステータスが設定されてもフィルタープロセスを停止も再起動もしません。ただし、Git は filter.<driver>.required フラグに従って終了コードを設定し、filter.<driver>.clean / filter.<driver>.smudge メカニズムの動作を模倣します。

フィルタが通信中に終了したり、プロトコルに従わない場合、Git はフィルタプロセスを停止し、処理する必要がある次のファイルで再開します。filter.<driver>.required フラグに応じて、Git はそれをエラーとして解釈します。

フィルターが「delay」機能をサポートしている場合、Git はフィルターコマンドとパス名の後に「can-delay」フラグを送信できます。このフラグは、フィルターが現在の BLOB のフィルタリングを遅延できること (例: ネットワーク遅延を補償するため) を、コンテンツなしで「delayed」ステータスとフラッシュパケットで応答することで示します。

フィルターが「delay」機能をサポートしている場合、「list_available_blobs」コマンドをサポートする必要があります。Git がこのコマンドを送信した場合、フィルターは以前に遅延され、現在利用可能になっている BLOB を表すパス名のリストを返すことが期待されます。リストはフラッシュパケットで終了し、その後に「success」ステータスが続き、これもフラッシュパケットで終了します。遅延されたパスの BLOB がまだ利用できない場合、フィルターは少なくとも1つの BLOB が利用可能になるまで応答をブロックすることが期待されます。フィルターは空のリストを送信することで、遅延された BLOB がもうないことを Git に伝えることができます。フィルターが空のリストで応答するとすぐに、Git は要求を停止します。この時点で Git が受信していないすべての BLOB は欠落していると見なされ、エラーになります。

Git がパス名を受信した後、対応する BLOB を再度要求します。これらの要求には、パス名と空のコンテンツセクションが含まれます。フィルターは、上記で説明した通常の方法で、smudge されたコンテンツで応答することが期待されます。

長時間実行されるフィルターのデモ実装は、Git コアのリポジトリにある contrib/long-running-filter/example.pl にあります。独自の長時間実行されるフィルタープロセスを開発する場合、GIT_TRACE_PACKET 環境変数はデバッグに非常に役立ちます (git[1] を参照)。

既存の filter.<driver>.clean または filter.<driver>.smudge コマンドは filter.<driver>.process と一緒に使用できないことに注意してください。これは、前者の2つは後者のものとは異なるプロセス間通信プロトコルを使用するためです。

チェックインコードパスでは、作業ツリーファイルはまず filter ドライバー (指定されていて対応するドライバーが定義されている場合) で変換され、次に結果は ident (指定されている場合) で処理され、最後に text (再び、指定されていて適用可能な場合) で処理されます。

チェックアウトコードパスでは、BLOB の内容はまず text で変換され、次に ident で変換されて filter に渡されます。

ファイルに属性を追加し、そのファイルの正規のリポジトリ形式が変更される場合 (クリーン/スマッジフィルターや text/eol/ident 属性の追加など)、属性が設定されていないものをマージすると、通常はマージの競合が発生します。

これらの不必要なマージの競合を防ぐために、Git は、3-way コンテンツマージが必要な各ファイルの3つのステージすべてについて、仮想チェックアウトとチェックインを実行するように指示できます。これは、merge.renormalize 設定変数を設定することで行います。これにより、変換されたファイルが変換されていないファイルとマージされたときに、チェックイン変換によって引き起こされる偽のマージの競合が防止されます。

"smudge→clean" が、すでにsmudgeされているファイルであっても "clean" と同じ出力になる限り、この戦略はすべてのフィルター関連の競合を自動的に解決します。この方法で動作しないフィルターは、手動で解決する必要がある追加のマージの競合を引き起こす可能性があります。

属性 diff は、Git が特定のファイルの差分を生成する方法に影響を与えます。パスに対してテキストパッチを生成するか、パスをバイナリファイルとして扱うかを Git に指示できます。また、ハunk ヘッダー @@ -k,l +n,m @@ 行に表示される行に影響を与えたり、差分を生成するために外部コマンドを使用するように Git に指示したり、差分を生成する前にバイナリファイルをテキスト形式に変換するように Git に要求したりすることもできます。

差分ドライバの定義は gitattributes ファイルではなく gitconfig で行われるため、厳密に言えばこのマニュアルページでそれを説明するのは適切ではありませんが…​

外部差分ドライバ jcdiff を定義するには、$GIT_DIR/config ファイル (または $HOME/.gitconfig ファイル) に次のようなセクションを追加します。

Git が diff 属性が jcdiff に設定されているパスの差分を表示する必要がある場合、上記の構成で指定したコマンド、つまり j-c-diff を、GIT_EXTERNAL_DIFF プログラムが呼び出されるのと同様に、7 つのパラメータで呼び出します。詳細については、git[1] を参照してください。

プログラムが特定の変更を無視できる場合 ( git diff --ignore-space-change と同様)、オプション trustExitCode も true に設定します。その場合、重要な変更が見つかった場合は終了コード 1 を返し、見つからない場合は 0 を返すことが期待されます。

差分アルゴリズムは diff.algorithm 設定キーで設定できますが、パスごとに差分アルゴリズムを設定すると便利な場合があります。たとえば、.json ファイルには minimal 差分アルゴリズムを、.c ファイルには histogram を使用したいが、毎回コマンドラインでアルゴリズムを渡す必要がない場合などです。

まず、.gitattributes でパスに diff 属性を割り当てます。

次に、「diff.<name>.algorithm」設定を定義して、差分アルゴリズムを「myers」、「patience」、「minimal」、「histogram」の中から指定します。

この差分アルゴリズムは、git-diff(1)、git-show(1) のようなユーザー向け差分出力に適用され、--stat 出力にも使用されます。マージ機構はこの方法で設定された差分アルゴリズムは使用しません。

テキスト差分出力の変更の各グループ (「ハunk」と呼ばれる) には、次の形式の行がプレフィックスされます。

これは ハunk ヘッダー と呼ばれます。"TEXT" 部分は、デフォルトではアルファベット、アンダースコア、またはドル記号で始まる行です。これは GNU diff -p 出力が使用するものと一致します。しかし、このデフォルトの選択は一部のコンテンツには適していないため、カスタマイズされたパターンを使用して選択できます。

まず、.gitattributes で、パスに diff 属性を割り当てます。

次に、「diff.tex.xfuncname」設定を定義して、ハunkヘッダー「TEXT」として表示させたい行に一致する正規表現を指定します。$GIT_DIR/config ファイル (または $HOME/.gitconfig ファイル) に次のようなセクションを追加します。

注: 設定ファイルパーサーによってバックスラッシュが1レベル消費されるため、バックスラッシュを二重にする必要があります。上記のパターンは、バックスラッシュで始まり、その後にゼロ個以上の sub が続き、その後に section が続き、その後に開き括弧が続き、行の終わりまでの行を選択します。

これを簡単にするための組み込みパターンがいくつかあり、tex もその1つなので、設定ファイルに上記を記述する必要はありません (ただし、.gitattributes を介して属性メカニズムでこれを有効にする必要はあります)。以下の組み込みパターンが利用可能です。

git diff --word-diff が行内の単語を分割するルールは、"diff.*.wordRegex" 設定変数に適切な正規表現を指定することでカスタマイズできます。たとえば、TeX ではバックスラッシュに続く文字のシーケンスがコマンドを形成しますが、いくつかのそのようなコマンドは間に空白を挟まずに続けて実行できます。それらを分離するには、$GIT_DIR/config ファイル (または $HOME/.gitconfig ファイル) に次のような正規表現を使用します。

前節に挙げたすべての言語に組み込みパターンが用意されています。

バイナリファイルのテキスト変換バージョンの差分を見たい場合があります。たとえば、ワープロドキュメントを ASCII テキスト表現に変換し、そのテキストの差分を表示できます。この変換は一部の情報を失いますが、結果の差分は人間が見るのに役立ちます (ただし、直接適用することはできません)。

textconv 設定オプションは、そのような変換を実行するためのプログラムを定義するために使用されます。プログラムは単一の引数、変換するファイル名を受け取り、結果のテキストを標準出力に出力する必要があります。

たとえば、バイナリ情報の代わりにファイルの exif 情報の差分を表示するには (exif ツールがインストールされていると仮定して)、$GIT_DIR/config ファイル (または $HOME/.gitconfig ファイル) に次のセクションを追加します。

テキスト変換は、特に git log -p で多数の変換を行う場合に遅くなる可能性があるため、Git は出力をキャッシュし、将来の差分でそれを使用するメカニズムを提供します。キャッシュを有効にするには、diff ドライバの設定で "cachetextconv" 変数を設定します。たとえば、

これにより、各 BLOB に対して「exif」を実行した結果が無期限にキャッシュされます。diff ドライバの textconv 設定変数を変更すると、Git は自動的にキャッシュエントリを無効にし、textconv フィルターを再実行します。キャッシュを手動で無効にしたい場合 (例: 「exif」のバージョンが更新され、より良い出力を生成するようになったため)、git update-ref -d refs/notes/textconv/jpg でキャッシュを手動で削除できます (ここで「jpg」は、上記の例のように diff ドライバの名前です)。

リポジトリ内のバイナリファイルまたは特殊な形式の BLOB 間の差分を表示したい場合、外部 diff コマンドを使用するか、textconv を使用して diff 可能なテキスト形式に変換するかを選択できます。どちらの方法を選択するかは、正確な状況によって異なります。

外部 diff コマンドを使用する利点は柔軟性です。行指向の変更を見つけることに拘束されず、出力が統一 diff に似ている必要もありません。データ形式に最も適切な方法で変更を見つけて報告することができます。

textconv は、それと比較して、はるかに制限があります。データの変換をライン指向のテキスト形式で提供し、Git は通常の diff ツールを使用して出力を生成します。この方法を選択する利点はいくつかあります。

Git は通常、内容の先頭を調べて、BLOB がテキストデータかバイナリデータかを正しく推測します。しかし、ファイルの後の方にバイナリデータが含まれている場合、または技術的にはテキスト文字で構成されているものの人間には意味不明な内容であるために、Git の判断を上書きしたい場合があります。たとえば、多くのポストスクリプトファイルは ASCII 文字のみを含んでいますが、ノイズが多く意味のない差分を生成します。

ファイルをバイナリとしてマークする最も簡単な方法は、.gitattributes ファイルで diff 属性を未設定にすることです。

これにより、Git は通常の差分の代わりに バイナリファイルが異なります (バイナリパッチが有効な場合はバイナリパッチ) を生成します。

ただし、他の diff ドライバー属性も指定したい場合があります。たとえば、ポストスクリプトファイルをテキスト表現に変換して人間が見やすくするために textconv を使用したいが、それ以外はバイナリファイルとして扱いたいとします。-diff と diff=ps の両方の属性を指定することはできません。解決策は、diff.*.binary 設定オプションを使用することです。

属性 merge は、git merge、および git revert や git cherry-pick などの他のコマンド中にファイルレベルのマージが必要な場合に、ファイルの3つのバージョンがどのようにマージされるかに影響を与えます。

merge 属性を介して要求できる、いくつかの組み込みの低レベルマージドライバが定義されています。

マージドライバの定義は gitattributes ファイルではなく .git/config ファイルで行われるため、厳密に言えばこのマニュアルページでそれを説明するのは不適切です。しかし…​

カスタムマージドライバ filfre を定義するには、$GIT_DIR/config ファイル (または $HOME/.gitconfig ファイル) に次のようなセクションを追加します。

merge.*.name 変数は、ドライバに人間が読める名前を与えます。

merge.*.driver 変数の値は、共通祖先のバージョン (%O)、現在のバージョン (%A)、および他のブランチのバージョン (%B) を実行するコマンドを構築するために使用されます。これらの3つのトークンは、コマンドラインが構築されるときにこれらのバージョンの内容を保持する一時ファイルの名前に置き換えられます。さらに、%L は競合マーカーサイズに置き換えられます (下記参照)。

マージドライバは、マージ結果を %A という名前のファイルに上書きして残し、クリーンにマージできた場合はゼロステータスで終了し、競合があった場合はゼロ以外のステータスで終了することが期待されます。ドライバがクラッシュした場合 (例: SEGV によって終了された場合)、128よりも高いゼロ以外のステータスで終了することが期待され、そのような場合、マージは失敗に終わります (これは競合を生成することとは異なります)。

merge.*.recursive 変数は、マージドライバが複数の共通祖先間の内部マージのために呼び出されたときに、どの他のマージドライバを使用するかを指定します。指定されていない場合、ドライバ自体が内部マージと最終マージの両方に使用されます。

マージドライバは、マージされた結果が保存されるパス名をプレースホルダー %P を介して学習できます。共通祖先、ローカルヘッド、および他のヘッドに使用される競合ラベルは、それぞれ %S、%X、および %Y を使用して渡すことができます。

この属性は、競合するマージ中に作業ツリーファイルに残される競合マーカーの長さを制御します。正の整数のみが意味のある効果を持ちます。

たとえば、.gitattributes のこの行は、ファイル Documentation/git-merge.adoc のマージが競合した場合に、マージ機構に通常よりもはるかに長い (通常の7文字ではなく) 競合マーカーを残すように指示するために使用できます。

core.whitespace 設定変数は、プロジェクト内のすべてのパスについて diff と apply が空白エラーと見なすべきものを定義することを可能にします (git-config[1] を参照)。この属性は、パスごとにきめ細かな制御を提供します。

export-ignore 属性を持つファイルとディレクトリは、アーカイブファイルに追加されません。

ファイルに export-subst 属性が設定されている場合、Git はこのファイルをアーカイブに追加する際にいくつかのプレースホルダーを展開します。展開はコミット ID の利用可能性に依存します。つまり、git-archive[1] にコミットまたはタグの代わりにツリーが与えられた場合、置換は行われません。プレースホルダーは git-log[1] のオプション --pretty=format: と同じですが、ファイル内で $Format:PLACEHOLDERS$ のように囲む必要があります。たとえば、文字列 $Format:%H$ はコミットハッシュに置き換えられます。ただし、サービス拒否攻撃を避けるため、アーカイブごとに展開される %(describe) プレースホルダーは1つだけです。

delta 属性が false に設定されているパスの BLOB に対しては、デルタ圧縮は試行されません。

この属性の値は、GUI ツール (gitk[1] や git-gui[1] など) が関連ファイルのコンテンツを表示するために使用すべき文字エンコーディングを指定します。パフォーマンス上の考慮事項から、gitk[1] は、オプションでファイルごとのエンコーディングを手動で有効にしない限り、この属性を使用しないことに注意してください。

この属性が設定されていないか無効な値の場合、代わりに gui.encoding 設定変数の値が使用されます (git-config[1] を参照)。