gitattributes(5) Manual Page

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

その他の値の場合、Gitは text が未指定(unspecified)であるかのように動作します。

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

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

Gitは通常、ファイルの内容をそのままにしますが、リポジトリ内で行末をLFに正規化し、オプションで、ファイルがチェックアウトされたときにCRLFに変換するように構成できます。

あなたが作業しているリポジトリに関係なく、あなたの作業ディレクトリ内でCRLF行末を設定したいだけの場合は、属性を使用せずに構成変数 core.autocrlf を設定できます。

これにより、テキストファイルの正規化は強制されませんが、リポジトリに導入するテキストファイルの行末は、追加時にLFに正規化され、リポジトリですでに正規化されているファイルは正規化されたままになります。

貢献者(contributor)がリポジトリに導入するテキストファイルの行末が正規化されていることを確認する場合は、「全て」のファイルに対して 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またはそのスーパーセットの1つ(UTF-8、ISO-8859-1など)でエンコードされたファイルをテキストファイルとして認識します。他の特定のエンコーディング(UTF-16など)でエンコードされたファイルはバイナリとして解釈されるため、組み込みのGitテキスト処理ツール(git diff など)や、ほとんどのGitWebフロントエンドはデフォルトでこれらのファイルのコンテンツを視覚化しません 。

このような場合、 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はチェックアウト時にブロブオブジェクト内の $Id$ を $Id: に置き換え、その後に40文字の16進ブロブオブジェクト名が続き、その後にドル記号 $ が続きます。ワークツリーファイルで $Id: で始まり、 $ で終わるバイトシーケンスは、チェックイン時に $Id$ に置き換えられます。

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

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

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

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

これらの2つのフィルターの振る舞いは異なり、デフォルトでは、フィルターは前者と見なされ、コンテンツをより便利な形にもみもみ(massage)します。構成にフィルタードライバー定義がないか、ゼロ以外のステータスで終了するフィルタードライバーはエラーではありませんが、フィルターを無操作パススルーにします。

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

注意: clean フィルターを変更するたびに、リポジトリを再正規化する必要があります: $ 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” と同等である必要があります)。 以下のmergingセクションを参照してください。

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

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

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

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

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

Gitは、クリーニング(cleaned)またはスマッジング(smudged)が必要な最初のファイルを検出すると、フィルターを開始してハンドシェイクを実行します。ハンドシェイクでは、Gitによって送信されるウェルカムメッセージは "git-filter-client" であり、プロトコルバージョン2("version=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" ステータスで応答することが期待されます。

"error"/"abort" ステータスが設定されている場合、Gitはフィルタープロセスを停止も再開もしません。 ただし、Gitは filter.<driver>.required`フラグに従って終了コードを設定し、 `filter.<driver>.clean / filter.<driver>.smudge メカニズムの振る舞いを真似っこします。

通信中にフィルターが停止した場合、またはプロトコルに準拠していない場合、Gitはフィルタープロセスを停止し、処理が必要な次のファイルでフィルターを再開します。 filter.<driver>.required フラグの設定によっては、Gitはそれをエラーとして解釈します。

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

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

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

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

既存の filter.<driver>.clean や filter.<driver>.smudge コマンドを filter.<driver>.process で使用できないことに注意してください。前者は後者とは異なるプロセス間通信プロトコルを使用するからです。

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

チェックアウトのコードの流れでは、ブロブコンテンツは最初に text で変換され、次に ident で変換され、 filter に送られます。

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

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

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

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

diffドライバの定義は gitattributes ファイルではなく gitconfig で行われるため、厳密に言えば、このマニュアルページはそれについて話すのには間違った場所はありますが…

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

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

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

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

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

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

テキストdiff出力の変更の各グループ(ハンク(hunk)と呼ばれます)には、以下の形式の行が接頭辞として付けられます:

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

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

次に、 diff.tex.xfuncname 構成を定義して、ハンクヘッダー "TEXT" として表示する行にマッチする正規表現を指定します。以下のように、 $GIT_DIR/config ファイル(または $HOME/.gitconfig ファイル)にセクションを追加します:

注意: 単一レベルのバックスラッシュは構成ファイルパーサーによって使用されるため、バックスラッシュを2重にする必要があります。 上記のパターンは、バックスラッシュで始まり、行の終わりまで、 sub 、 section 、 { の順に0回以上出現する行を選択します。

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

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

前のセクションにリストされているすべての言語には組み込みのパターンが用意されています。

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

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

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

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

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

あなたがリポジトリ内のバイナリまたは特別にフォーマットされたブロブの違いを表示したい場合は、外部のdiffコマンドを使用するか、textconvを使用してそれらを差分可能(diff-able)なテキストフォーマットに変換するかを選択できます。どちらの方法を選択するかは、状況に完全に依存します。

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

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

Gitは通常、コンテンツの先頭を調べることで、ブロブにテキストデータとバイナリデータのどちらが含まれているかを正しく推測します。ただし、ブロブにファイルの後半にバイナリデータが含まれている、またはコンテンツが技術的にはテキスト文字で構成されているものの、人間の読者には不明瞭であるために、あなたは、その推測を上書きしたい場合があります。たとえば、多くのポストスクリプトファイルにはASCII文字しか含まれていません(つまりテキストデータです)が、ノイズが多く意味のないdiffが生成されます。

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

これにより、Gitは通常の差分ではなく Binary files differ (バイナリファイルの差分)(またはバイナリパッチが有効になっている場合はバイナリパッチ)を生成します。

しかしながら、他のdiffドライバー属性を指定することもできます。 たとえば、 textconv を使用してポストスクリプトファイルをASCII表現に変換し、人間が表示できるようにしたい場合があるけども、それ以外の場合はバイナリファイルとして扱いたいとします。 -diff 属性 と diff=ps 属性の両方を指定することはできません。 解決策は、 diff.*.binary 構成オプションを使用することです:

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

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

マージドライバの定義は、 gitattributes ファイルではなく .git/config ファイルで行われるため、厳密に言えば、このマニュアルページはそれについて話すのに間違った場所ではありますが…

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

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

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

マージドライバーは、マージの結果を %A という名前のファイルに上書きして残し、それらを正常にマージできた場合はゼロステータスで終了し、競合があった場合は非ゼロで終了することが期待されます。ドライバーがクラッシュした場合(SEGV によって kill された場合など)、ドライバーは 128 を超えるゼロ以外のステータスで終了(exit)すると期待され、かつ、そのような場合、マージは失敗(failure)します(これは競合の発生とは異なります)。

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

マージドライバーは、プレースホルダー %P を介して、マージされた結果が格納されるパス名を知ります。

この属性は、競合するマージ中に作業ツリーファイルに残る競合マーカーの長さを制御します。値を正の整数に設定するだけで、意味のある効果があります。

たとえば、 ファイル Documentation/git-merge.txt の結果をマージすると競合するときに、.gitattributes で(通常の7文字の長さではなく)はるかに長い競合マーカーを残すようにマージ機構に指示できます。

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

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

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

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

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