この属性は、パスをテキストファイルとしてマークし、これにより改行変換が有効になります。一致するファイルがインデックスに追加されると、ファイルの改行はインデックス内で 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 属性を unset してください。

逆に、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 属性を使用すると、多くの落とし穴がある可能性があることに注意してください。

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

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

BOM なしの UTF-16 リトルエンディアンで *`*.ps1`* ファイルがエンコードされており、ワーキングディレクトリで Windows の行末を使用する場合は、次の属性を使用します（UTF-16 リトルエンディアンを BOM 付きで使用する場合は、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 のみを処理して終了します。長時間実行される process フィルターが clean および/または smudge フィルターの代わりに使用される場合、Git は単一の Git コマンドのライフサイクル全体（たとえば git add --all）で、単一のフィルターコマンド呼び出しですべての BLOB を処理できます。長時間実行される process フィルターが構成されている場合は、構成された単一の BLOB フィルターよりも常に優先されます。process フィルターとの通信に使用されるプロトコルの説明については、以下のセクションを参照してください。

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

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

これら 2 つのフィルターは動作が異なり、デフォルトでは、フィルターは前者のように、コンテンツをより便利な形に整形するものとして扱われます。構成内のフィルタードライバー定義の欠落、またはゼロ以外のステータスで終了するフィルタードライバーは、エラーではなく、フィルターを no-op パススルーにします。

フィルターの .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を単一のフィルター呼び出しで処理できます。これは、長時間実行されるプロセスプロトコル（technical/long-running-process-protocol.txtで説明）を使用することで実現されます。

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

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

フィルターは、フラッシュパケットで終端された「key=value」ペアのリストで応答することが期待されます。フィルターに問題がない場合、リストには「success」ステータスを含める必要があります。これらのパケットの直後、フィルターは0個以上のpkt-lineパケットでコンテンツを送信し、最後にフラッシュパケットを送信することが期待されます。最後に、フラッシュパケットで終端された「key=value」ペアの2番目のリストが期待されます。フィルターは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 に渡されます。

clean/smudgeフィルターやtext/eol/ident属性の追加など、ファイルの正規リポジトリ形式を変更する属性をファイルに追加した場合、その属性が存在しないものをマージすると、通常はマージの競合が発生します。

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

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

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

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

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

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

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

diffアルゴリズムは、diff.algorithm 構成キーを介して設定できますが、パスごとにdiffアルゴリズムを設定すると便利な場合があります。たとえば、.jsonファイルには minimal diffアルゴリズムを、.cファイルには histogram を使用するなど、毎回コマンドラインでアルゴリズムを渡さなくても済むようにすることができます。

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

次に、myers、patience、minimal、または histogram から選択して、diffアルゴリズムを指定するための「diff.<name>.algorithm」構成を定義します。

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

テキスト形式のdiff出力の変更グループ（「hunk」と呼ばれる）には、次の形式の行が前に付加されます

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

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

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

注意。構成ファイルパーサーによってバックスラッシュが1つ削除されるため、バックスラッシュを2つにする必要があります。上記のパターンは、バックスラッシュで始まり、0回以上のsub、それに続くsection、それに続く開き波括弧で終わる行を選択します。

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

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

組み込みパターンが、前のセクションにリストされているすべての言語に対して提供されています。

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

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

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

テキスト変換は、特にgit log -pで多数の変換を行う場合に時間がかかる可能性があるため、Gitは出力をキャッシュし、将来のdiffで使用するメカニズムを提供します。キャッシュを有効にするには、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文字のみが含まれていますが、ノイズが多く意味のないdiffが生成されます。

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

これにより、Gitは通常のdiffの代わりにBinary files differ（またはバイナリパッチが有効になっている場合はバイナリパッチ）を生成します。

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

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

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

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

カスタムマージドライバ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.txt のマージでコンフリクトが発生した場合に、マージ機構に（通常の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つのアーカイブにつき 1 つの %(describe) プレースホルダーのみが展開されます。

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

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

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