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

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

この属性は、パスをチェックアウトする際に、ワーキングツリーで特定の行末スタイルを使用するようにマークします。これは、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ウェブフロントエンドは、デフォルトではこれらのファイルの内容を視覚化しません。

このような場合、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にプラットフォームに基づいて自動行末変換を実行させたい場合、以下の属性を使用します。

BOMなしでUTF-16リトルエンディアンでエンコードされた*.ps1ファイルがあり、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フィルターとの通信に使用されるプロトコルの説明については、以下のセクションを参照してください。

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

コンテンツフィルタリングのもう一つの用途は、リポジトリで直接使用できないコンテンツ（例：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フィルターが自身の出力を変更せずに受け入れなければならないことを意味します。

格納されたコンテンツを使用可能にするためにフィルターが必ず成功しなければならない場合、設定でそのフィルターがrequiredであると宣言できます。

フィルターコマンドラインのシーケンス「%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はフラッシュパケットで終了する「キー=値」のペアのリストを送信します。このリストには、少なくともフィルターコマンド（サポートされる機能に基づく）と、リポジトリのルートに対するフィルター対象ファイルのパス名が含まれます。フラッシュパケットの直後、Gitは0個以上のpkt-lineパケットで分割されたコンテンツと、コンテンツを終了させるためのフラッシュパケットを送信します。フィルターはコンテンツと最終的なフラッシュパケットを受信する前に、いかなる応答も送信してはならないことに注意してください。また、「キー=値」ペアの「値」は「=」文字を含むことができますが、キーはこの文字を絶対に含みません。

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

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

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

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

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

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を表すパス名のリストを返すことが期待されます。リストはフラッシュパケットで終了し、それに続く「成功」ステータスもフラッシュパケットで終了しなければなりません。遅延されたパスのBLOBがまだ利用可能でない場合、フィルターは少なくとも1つのBLOBが利用可能になるまで応答をブロックすることが期待されます。フィルターは空のリストを送信することで、遅延されたBLOBがもうないとGitに伝えることができます。フィルターが空のリストで応答するとすぐに、Gitは問い合わせを停止します。この時点でGitが受信していないすべてのBLOBは不足していると見なされ、エラーになります。

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

長時間実行フィルターのデモ実装は、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属性の追加など、ファイルの正規リポジトリ形式を変更する属性をファイルに追加した場合、属性が適用されていないものをマージすると、通常はマージ競合が発生します。

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

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

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

diffドライバーの定義はgitattributesファイルではなくgitconfigで行うため、厳密に言えばこのマニュアルページで話すのは場違いです。しかし…​

外部diffドライバー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アルゴリズムはdiff.algorithm設定キーを介して設定できますが、パスごとにdiffアルゴリズムを設定すると便利な場合があります。たとえば、.jsonファイルにはminimal diffアルゴリズムを、.cファイルにはhistogramを、といったように、毎回コマンドラインでアルゴリズムを渡す必要がありません。

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

次に、"diff.<name>.algorithm" の設定を定義して、myers, patience, minimal, histogramの中から選択したdiffアルゴリズムを指定します。

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

テキスト差分出力の各変更グループ（「hunk」と呼ばれる）は、次の形式の行でプレフィックスされます。

これはhunkヘッダーと呼ばれます。「TEXT」部分は、デフォルトではアルファベット、アンダースコア、またはドル記号で始まる行です。これはGNU diff -pの出力が使用するものと一致します。しかし、このデフォルトの選択は一部のコンテンツには適しておらず、カスタムパターンを使用して選択を行うことができます。

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

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

注意：設定ファイルのパーサーによってバックスラッシュが1レベル消費されるため、バックスラッシュを2重にする必要があります。上記のパターンは、バックスラッシュで始まり、0個以上のsubの後にsection、さらにオープンブレースが続き、行末まで続く行を選択します。

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

git diff --word-diffが1行内で単語を分割するために使用するルールは、"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がテキストデータかバイナリデータかを正しく推測します。しかし、時にはその決定を上書きしたい場合があります。BLOBがファイルの後方でバイナリデータを含んでいるため、または内容が技術的にはテキスト文字で構成されているものの、人間には不透明であるためです。たとえば、多くのPostScriptファイルはASCII文字のみを含んでいますが、ノイズが多く無意味な差分を生成します。

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

これにより、Gitは通常の差分ではなく、Binary files differ（またはバイナリパッチが有効な場合はバイナリパッチ）を生成します。

ただし、他のdiffドライバ属性も指定したい場合があります。たとえば、PostScriptファイルを人間が見るためにASCII表現に変換するために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$はコミットハッシュに置き換えられます。ただし、サービス拒否攻撃を避けるため、アーカイブごとに1つの%(describe)プレースホルダーのみが展開されます。

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

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

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