git-show

Contents

コマンド名

「git-show」:様々な種類のオブジェクトを表示

概要

git show [<options>] [<object>…]

説明

1つ以上のオブジェクト(ブロブ、ツリー、タグ、およびコミット)を表示します。

コミットの場合、ログメッセージとテキストの差分が表示されます。また「git diff-tree—cc」によって作成された特別なフォーマットでマージコミットを示します。

タグの場合、タグメッセージと参照オブジェクトが表示されます。

ツリーの場合、名前が表示されます(「–name-only」を指定した「git ls-tree」と同等)。
プレーンブロブの場合、プレーンコンテンツが表示されます。

このコマンドは「git diff-tree」コマンドに適用可能なオプションを使用し、コミットによって導入された変更の表示方法をコントロールします。

このマニュアルページでは、最も頻繁に使用されるオプションについてのみ説明しています。

オプション

<object>…

表示するオブジェクトの名前(デフォルトではヘッド)です。オブジェクト名を記載する方法のより完全なリストについてはgitrevisions[7]の「SPECIFYINGREVISIONS」セクションを参照してください。

--pretty[=<format>]
--format=<format>

コミットログの内容を指定されたフォーマットでプリティプリントします。<format>は「oneline、short、medium、full、fuller、reference、email、raw、format:<string>、tformat:<string>」のいずれかになります。<format>が上記のいずれでもなく、「%placeholder」が含まれている場合、「-pretty = tformat:<format>」が指定されたかのように機能します。

各フォーマットの詳細については「PRETTYFORMATS」セクションを参照してください。 <format>の部分を省略すると、デフォルトで「medium」になります。
注記:リポジトリー構成でデフォルトのプリティフォーマットを指定できます(git-config[1]を参照してください)。

--abbrev-commit

40バイトの16進コミットオブジェクト名全体を表示する代わりに部分的なプレフィックスのみを表示します。デフォルト以外の桁数は「-abbrev = <n>」で指定できます(これは表示されている場合、差分出力も変更します)。

これにより80列の末端を使用している人にとって「–pretty = oneline」がずっと読みやすくなるはずです。

--no-abbrev-commit

完全な40バイトの16進コミットオブジェクト名を表示します。これにより明示的または「–oneline」などの他のオプションによって暗示される--abbrev-commitが無効になります。また、log.abbrevCommit変数を上書きします。

--oneline

これは「-pretty = oneline–abbrev-commit」を一緒に使用するための省略形です。

--encoding=<encoding>

コミットオブジェクトはログメッセージに使用されるエンコーディングをエンコーディングヘッダーに記録します。このオプションを使用して、ユーザーが好むエンコーディングでコミットログメッセージを再コーディングするようにコマンドに指示できます。非配管コマンドの場合、これはデフォルトでUTF-8になります。オブジェクトがXでエンコードされていると主張し、Xで出力している場合、オブジェクトを逐語的に出力することに注意してください。これはオリジナルのコミットの無効なシーケンスが出力にコピーされる可能性があることを意味します。

--expand-tabs=<n>
--expand-tabs
--no-expand-tabs

出力に表示する前にログメッセージでタブ展開を実行します(各タブを<n>の倍数である次の表示列に入力するのに十分なスペースで置き換えます)。--expand-tabs--expand-tabs=8の省略形であり、--no-expand-tabsは--expand-tabs=0の省略形であり、タブの展開を無効にします。

デフォルトではタブはログメッセージを4スペースでインデントするきれいなフォーマットで展開されます(つまり、「default」、「full」、 「fuller」である「medium」です。)。

--notes[=<ref>]

コミットログメッセージを表示する時、コミットに注釈を付けるメモ(git-notes[1]を参照)を表示します。これは、コマンドラインに—pretty--format--onelineオプションが指定されていない場合、git loggit showgit whatchanged コマンドのデフォルトとなります。

デフォルトでは表示されるメモは、core.notesRefnotes.displayRef 変数(または対応する環境を上書き)にリスト化されているメモ参照からのものです。詳細についてはgit-config[1] を参照してください。

オプションの<ref>引数を使用して、参照を使用して表示するメモを検索します。参照はrefs/notes/で始まる完全な参照名を指定できます。notes/で始まる場合、refs/であり、それ以外の場合はrefs/notes/が接頭辞として付けられ、参照名のフルネームが作成されます。

複数の「--notes」オプションを組み合わせて、表示するノートをコントロールできます。例えば、「-notes = foo」は「refs / notes / foo」からのメモのみを表示します。「–notes = foo –notes」は「refs / notes / foo」とデフォルトの「notesref(s)」の両方のメモを表示します。

--no-notes

ノートを表示しません。これはノートが表示されるノート参照のリストをリセットすることにより、上記の--notesオプションを無効にします。オプションはコマンドラインで指定された順序で解析されます。「–notes–notes = foo –no-notes –notes = bar」は「refs / notes / bar」からのメモのみを表示します。

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

これらのオプションは非推奨となっています。代わりに上記の「–notes / -no-notes」オプションを使用してください。

--show-signature

署名をgpg --verify にパスして、署名されたコミットオブジェクトの有効性を確認し、出力を表示します。

PRETTY FORMATS

コミットがマージであり、「pretty-format」が「oneline、email、またはraw」でない場合、「Author」の前に追加のラインが挿入されます。このラインは「Merge:」で始まり、先祖のコミットのハッシュがスペースで区切られて印刷されます。履歴の表示を制限している場合、例えば特定のディレクトリまたはファイルに関連する変更のみに関心がある場合、リストされたコミットが必ずしも直接のペアレントコミットのリストであるとは限らないことに注意してください。

いくつかの組み込みフォーマットがあり、以下で説明するように、「pretty.<name>」 構成オプションを別のフォーマット名または「format:string」に設定することで、追加のフォーマットを定義できます(git-config[1]を参照)。組み込みフォーマットの詳細は次のとおりです。

  • oneline
    <hash> <title line>
    

    これは可能な限りコンパクトになるように設計されています。

  • short
    commit <hash>
    Author: <author>
    
    <title line>
    
  • medium
    commit <hash>
    Author: <author>
    Date:   <author date>
    
    <title line>
    
    <full commit message>
    
  • full
    commit <hash>
    Author: <author>
    Commit: <committer>
    
    <title line>
    
    <full commit message>
    
  • fuller
    commit <hash>
    Author:     <author>
    AuthorDate: <author date>
    Commit:     <committer>
    CommitDate: <committer date>
    
    <title line>
    
    <full commit message>
    
  • reference
    <abbrev hash> (<title line>, <short author date>)
    

    このフォーマットはコミットメッセージ内の別のコミットを参照するために使用され、--pretty='format:%C(auto)%h (%s, %ad)'と同じです。デフォルトでは別の--dateオプションが明示的に指定されていない限り、日付は--date=shortでフォーマットされます。他のformat:と同様に、フォーマットプレースホルダーを使用するとその出力は—decorate--walk-reflogsなどの他のオプションの影響を受けません。

  • email
    From <hash> <date>
    From: <author>
    Date: <author date>
    Subject: [PATCH] <title line>
    
    <full commit message>
    
  • mboxrd
    「email」と同様ですが、コミットメッセージの「From」で始まるライン(前に0個以上の「>」が付いている)は「>」で引用されているため、新しいコミットの開始と混同されることはありません。
  • raw
    「raw」フォーマットではコミットオブジェクトに格納されているとおりにコミット全体が表示されます。特に「-abbrev」または「–no-abbrev」のどちらが使用されているかに関係なく、ハッシュは完全に表示され、ペアレント情報は移植や履歴の単純化を考慮せずに、真のペアレントコミットを示します。このフォーマットはコミットの表示方法に影響しますが、差分の表示方法には影響しないことに注意してください。git log --rawを使用します。 ロー差分フォーマットで完全なオブジェクト名を取得するには--no-abbrevを使用します。
  • format:<string>
    「format:<string>」フォーマットを使用すると、表示する情報を指定できます。これは「printf」フォーマットと少し似ていますが、「\ n」の代わりに「%n」を使用して改ラインを取得するという注目すべき例外があります。
    例えば、「format:”The author of %h was %an, %ar%nThe title was >>%s<<%n”」は次のように表示されます。

    The author of fe6e0ee was Junio C Hamano, 23 hours ago
    The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
    

    プレースホルダーは次のとおりです。

    • シングルのリテラル文字に展開されるプレースホルダー:
      • %n
        新ライン
      • %%
        ロー%
      • %x00
        16進コードから1バイトを出力します
    • プレースホルダーのフォーマットに影響するプレースホルダー
      • %Cred
        色を赤に切り替えます
      • %Cgreen
        色を緑に切り替えます
      • %Cblue
        色を青に切り替えます
      • %Creset
        色をリセットします
      • %C(…)
        git-config[1].の「CONFIGURATIONFILE」セクションの「Values」で説明されている色の指定です。 デフォルトでは色はログ出力が有効になっている場合にのみ表示されます(color.diffcolor.ui--colorによって、ターミナルに移動する場合は前者の自動設定を優先します)。%C(auto,...)はデフォルトの履歴同義語として受け入れられます(例えば%C(auto,red)です。%C(always,...) を指定すると、色が有効になっていない場合でも色が表示されます(ただしこのフォーマットやgitが色付けする可能性のあるものを含め、出力全体の色を有効にするには、--color=alwaysを使用することを検討してください)autoのみ(つまり%C(auto))は色が再び切り替わるまで、次のプレースホルダーで自動色付けをオンにします。
      • %m
        左(<)、右(>)またバウンダリー(-)マーク
      • %w([<w>[,<i1>[,<i2>]]])
        git-shortlog[1]の「-w」オプションのように、ラインの折り返しを切り替えます。
      • %<(<N>[,trunc|ltrunc|mtrunc])
        次のプレースホルダーに少なくともN列を使用させ、必要に応じて右側にスペースを埋め込みます。 オプションで出力がN列より長い場合は最初(ltrunc)、中間(mtrunc)、または最後(trunc)で切り捨てます。切り捨てはN> = 2でのみ正しく機能することに注意してください。
      • %<|(<N>)
        次のプレースホルダーを少なくともN番目の列まで取得し、必要に応じて右側にスペースを埋めます。
      • %>(<N>), %>|(<N>)
        それぞれ「%<(<N>)、%<|(<N>)」と同様ですが、左側にスペースが埋め込まれています。
      • %>>(<N>), %>>|(<N>)
        それぞれ「%>(<N>)、%> |(<N>)」と同様ですが、次のプレースホルダーが指定されたよりも多くのスペースを取り、その左側にスペースがある場合はそれらのスペースを使用します。
      • %><(<N>), %><|(<N>)
        それぞれ「%<(<N>)、%<|(<N>)」と同様ですが、両側にパディングがあります(つまり、テキストが中央に配置されます)
    • コミットから抽出された情報に展開するプレースホルダー
      • %H
        コミットハッシュ
      • %h
        省略されたコミットハッシュ
      • %T
        ツリーハッシュ
      • %t
        省略されたツリーハッシュ
      • %P
        ペアレントハッシュ
      • %p
        省略されたペアレントハッシュ
      • %an
        作成者名
      • %aN
        作成者名 (mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      • %ae
        作成者のメール
      • %aE
        作成者のメール(mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      • %al
        作成者のメールローカルパート(@ サインの前のパート)
      • %aL
        作成者のローカルパート(%alを参照) (mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      • %ad
        作成日 (フォーマット、日付オプション)
      • %aD
        作成日RFC2822 スタイル
      • %ar
        作成日, 関連
      • %at
        作成日, UNIX テストスタンプ
      • %ai
        作成日、ISO 8601のようなフォーマット
      • %aI
        作成日、厳密なISO 8601フォーマット
      • %as
        作成日、ショートフォーマット(YYYY-MM-DD)
      • %cn
        コミッター名
      • %cN
        コミッター名(mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      • %ce
        コミッターのメール
      • %cE
        コミッターのメール(mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      • %cl
        コミッターのメールローカルパート(@ サインの前のパート)
      • %cL
        コミッターのローカルパート(%clを参照、 mailmapについては git-shortlog[1] or git-blame[1] を参照してください)
      • %cd
        コミッター日(フォーマット、日付オプション)
      • %cD
        コミッター日、RFC2822スタイル
      • %cr
        コミッター日、関連
      • %ct
        コミッター日、UNIXタイムスタンプ
      • %ci
        コミッター日、ISO 8601のようなフォーマット
      • %cI
        コミッター日、厳密なISO 8601フォーマット
      • %cs
        コミッター日、ショートフォーマット(YYYY-MM-DD)
      • %d
        参照名、git-log[1]のオプションのデコレート
      • %D
        参照名、「”(“, “)」のラッピングなし
      • %S
        コミットに到達したコマンドラインで指定された参照名(git log --sourceなど)はgit logでのみ機能
      • %e
        エンコーディング
      • %s
        件名
      • %f
        ファイル名に適するようにサニタイズされた件名
      • %b
        本文
      • %B
        原文(件名および本文にラップされていない)
      • %N
        コミットノート
      • %GG
        署名されたコミットに対するGPGからの生の検証メッセージ
      • %G?
        問題のない(有効な)署名の場合は「G」、問題のある署名の場合は「B」、有効期限が不明な問題のない署名の場合は「U」、期限切れの問題のない署名の場合は「X」、期限の切れたキーで作成された問題のない署名の場合は「Y」、取り消されたキーによって作成された問題のない署名の場合は「R」、署名を確認できない場合(キーの欠落など)は「E」、署名がない場合は「N」と表示します。
      • %GS
        署名されたコミットの署名者の名前を表示する
      • %GK
        署名されたコミットに署名するために使用されるキーを表示する
      • %GF
        署名されたコミットに署名するために使用されるキーの指紋を表示する
      • %GP
        署名されたコミットに署名するためにサブキーが使用された主キーの指紋を表示する
      • %GT
        署名されたコミットに署名するために使用されるキーの信頼レベルを表示する
      • %gD
        参照ログセレクター(例えば、refs/stash@{1}もしくは refs/stash@{2 minutes ago} フォーマットは-gオプションで説明されている規則に従います。@の前の部分はコマンドラインで指定された参照名です(したがって、git log -g refs/heads/masterはrefs/heads/master@{0}を作成します)。
      • %gd
        短縮参照ログセレクターです。%gDと同じですが、人が読みやすいように参照名部分が短縮されています(したがって、refs/heads/master は単なるmasterになります)。
      • %gn
        参照ログID名
      • %gN
        参照ログID名(mailmapについてはgit-shortlog[1]もしくは git-blame[1]を参照してください)
      • %ge
        参照ログIDメール
      • %gE
        参照ログIDメール(mailmapについてはgit-shortlog[1]もしくは git-blame[1]を参照してください)
      • %gs
        参照ログ件名
      • %(trailers[:options])
        git-interpret-trailers[1]によって解釈された本文のトレーラーを表示します。trailers文字列の後にはコロンと0個以上のコンマ区切りオプションを続けることができます。
      • key=<K>: 指定されたキーのトレーラーのみを表示します。マッチングは大文字と小文字を区別せずに行われ、末尾のコロンはオプションです。オプションが複数回指定されている場合、いずれかのキーに一致するトレーラーラインが表示されます。このオプションは自動的にonlyオプションを有効にして、トレーラーブロック内の非トレーラーラインを非表示にします。それが望ましくない場合はonly=falseで無効にすることができます。例えば%(trailers:key=Reviewed-by) はキーがReviewed-byのトレーラーを表示します。
      • only[=val]:トレーラーブロックからの非トレーラーラインを含めるかどうかを選択します。only キーワードの後には、オプションでtrueonyes のいずれかを省略したり、falseoffno のいずれかを付けてトレーラー以外のラインを表示したりできます。オプションが値なしで指定された場合、それが有効になります。複数回指定すると、最後の値が使用されます。
      • separator=<SEP>:トレーラーラインの間に挿入される区切り記号を指定します。このオプションが指定されていない場合、各トレーラーラインは改ライン文字で終了します。文字列SEPには上記のリテラルフォーマットコードが含まれる場合があります。区切り文字としてコンマを使用するには次のオプションとして解析するため、%x2C を使用する必要があります。セパレータオプションを複数回指定すると、最後のオプションのみが使用されます。例えば%(trailers:key=Ticket,separator=%x2C ) はキーが「チケット」であるすべてのトレーラーラインをカンマとスペースで区切って表示します。
      • unfold[=val]:まるでインタープレットトレーラーの--unfoldオプションが指定されたかのように機能します。onlyの場合と同じように、等号と明示的な値を続けることができます。例えば%(trailers:only,unfold=true)は展開され、すべてのトレーラーラインが表示されます。
      • valueonly[=val]:トレーラーラインの重要な部分をスキップして、値の部分のみを表示します。またこれはオプションで明示的な値を許可します。

    注記 一部のプレースホルダーはリビジョントラバーサルエンジンに指定された他のオプションに依存する場合があります。例えば%g* 参照ログオプションは参照ログエントリをトラバースしない限り(例えば、git log -gによって)、空の文字列を挿入します。%d および %Dプレースホルダーはコマンドラインで--decorateがまだ指定されていない場合、「ショート」とデコレーションフォーマットを使用します。

    プレースホルダーの%の後に+(プラス記号)を追加すると、プレースホルダーが空でない文字列に展開される場合に限り、展開の直前に改ラインが挿入されます。
    プレースホルダーの%の後に-(マイナス記号)を追加すると、プレースホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべての改ラインが削除されます。

    プレースホルダーの%の後に「 “」(スペース)を追加すると、プレースホルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入されます。

    • tformat:
      「tformat」:フォーマットは「separator」セマンティクスの代わりに「terminator」セマンティクスを提供することを除き、フォーマットとまったく同じように機能します。つまり各コミットにはエントリ間に区切り文字を配置するのではなく、メッセージターミネータ文字(通常は改ライン)が追加されます。これは「1ライン」フォーマットと同様に1ラインフォーマットの最終エントリが新しいラインで適切に終了することを意味します。 例えば、次のような形です。

      $ git log -2 --pretty=format:%h 4da45bef \
      	| perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
      4da45be
      7134973 -- NO NEWLINE
      
      $ git log -2 --pretty=tformat:%h 4da45bef \
      	| perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
      4da45be
      7134973
      

      さらに%が含まれている認識されない文字列は、その前にtformat:があるかのように解釈されます。例えば、これら2つは同等となります。

      $ git log -2 --pretty=tformat:%h 4da45bef
      $ git log -2 --pretty=%h 4da45bef
      

      共通の差分オプション

      -p
      -u
      --patch

      パッチを作成します(パッチの作成に関するセクションを参照)。

      -s
      --no-patch

      差分出力を抑制します。デフォルトでパッチを表示するgit show のようなコマンド、または--patchの効果をキャンセルする場合に便利です。

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

      通常の3ラインではなく、<n>ラインのコンテキストで差分を作成します。–patchを意味します。-pを意味します。

      --output=<file>

      「stdout」ではなく特定のファイルに出力します。

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

      作成されたパッチの新しいライン、古いライン、またはコンテキストラインを示すために使用される文字を指定します。通常、それらはそれぞれ「+」、「-」、および「 ”」となります。

      --raw

      コミットごとに、ロー差分フォーマットを使用して変更の概要を表示します。git-diff[1]の「ロー出力フォーマット」セクションを参照してください。これはログ自体をローフォーマットで表示することとは異なり、--format=rawで実現できます。

      --patch-with-raw

      -p –rawとの同義語です。

      -t

      差分出力にツリーオブジェクトを表示します。

      --indent-heuristic

      差分ハンクのバウンダリーをシフトするヒューリスティックを有効にして、パッチを読みやすくします。これがデフォルトとなります。

      --no-indent-heuristic

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

      --minimal

      可能な限り最小の差分となるように、時間を使います。

      --patience

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

      --histogram
      アルゴリズムを使用して差分を作成します。

      --anchored=<text>

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

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

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

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

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

      default, myers

      基本的なグリーディー差分アルゴリズムとなります。 現在これがデフォルトとなります。

      minimal

      可能な限り最小の差分となるように、時間を使います。

      patience

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

      histogram

      このアルゴリズムはペイシェントアルゴリズムを拡張し、「発生率の低い共通エレメントをサポート」します。

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

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

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

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

      --compact-summary

      ファイルの作成または削除(「新規」または「終了」、オプションでシンボリックリンクの場合は「+ l」)および「diffstat」におけるモード変更(追加または削除の場合は「+ x」または「-x」)などの拡張ヘッダー情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置かれます。--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

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

      --patch-with-stat

      -p –statと同義語です。

      -z

      新しい改ラインではなく、NULでコミットを区切ります。

      また、--rawまたは--numstatが指定されている場合、パス名を変更したり、出力フィールドターミネータとしてNULを使用したりしないでください。

      このオプションがないと、構成変数core.quotePathで説明されているように「異常な」文字を含むパス名が引用符で囲まれます(git-config[1]を参照)。

      --name-only

      変更されたファイルの名前のみを表示します。

      --name-status

      変更されたファイルの名前とステータスのみを表示します。ステータス文字の意味については--diff-filterオプションの説明を参照してください。

      --submodule[=<format>]

      サブモジュールの違いをどのように表示するかを指定します。--submodule=shortを指定すると、ショートフォーマットが使用されます。このフォーマットは範囲の最初と最後にコミットの名前を表示するだけです。--submoduleまたは--submodule=logを指定すると、ログフォーマットが使用されます。このフォーマットはlike git-submodule[1]の要約のように範囲内のコミットをリスト化します。--submodule=diffを指定すると、差分フォーマットが使用されます。このフォーマットはコミット範囲間のサブモジュールの内容の変更のインライン差分を示します。構成オプションが設定されていない場合、デフォルトはdiff.submoduleまたはショートフォーマットです。

      --color[=<when>]

      色付きの差分を表示します。--color=always(つまり、「without =<when>」)は差分--color と同じです。<when>はalwaysnever、またはautoのいずれかになります。

      --no-color

      色付きの差分をオフにします。--color=neverと同じです。

      --color-moved[=<mode>]

      移動したコードラインの色は異なります。<mode>はオプションが指定されていない場合はデフォルトで「no」になり、モードが指定されていない場合は「zebra」になります。モードは次のいずれかである必要があります。

      no

      移動したラインはハイライトしません。

      default

      zebraの同義語です。これは将来よりセンシブルなモードに変更される可能性があります。

      plain

      ある場所で追加され、別の場所で削除されたラインは「color.diff.newMoved」で色付けされます。 同様に「color.diff.oldMoved」は差分の別の場所に追加された削除されたラインに使用されます。このモードは移動されたラインをピックアップしますが、コードのブロックが順列なしで移動されたかどうかを判断することはレビューではあまり役に立ちません。

      blocks

      少なくとも20文字の英数字の移動テキストのブロックがグリーディーに検出されます。検出されたブロックは「color.diff.{old,new}Moved」色のいずれかを使用してペイントされます。隣接するブロックを区別することはできません。

      zebra

      移動したテキストのブロックは「blocks」モードの場合と同様に検出されます。ブロックは「color.diff.{old,new}Moved」色または「color.diff.{old,new}MovedAlternative」のいずれかを使用してペイントされます。2つの色の間の変化は新しいブロックが検出されたことを示します。

      dimmed-zebra

      「zebra」と同様ですが、移動されたコードに関連ない部分に追加のディミングが実行されます。隣接する2つのブロックのバウンダリーラインは関連があると見なされ、残りは関連が深いものではありません。dimmed_zebraは非推奨の同義語です。

      --no-color-moved

      移動検出をオフにします。これは構成設定を上書きするために使用できます。--color-moved=noと同じです。

      --color-moved-ws=<modes>

      これは--color-movedの移動検出を実行するときに空白を無視する方法を構成します。これらのモードはコンマ区切りのリストとして指定できます。

      no

      移動検出を実行する時、空白を無視しません。

      ignore-space-at-eol

      EOLで空白の変更を無視します。

      ignore-space-change

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

      ignore-all-space

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

      allow-indentation-change

      最初に移動検出で空白を無視し、空白の変更がラインごとに同じである場合にのみ、移動されたコードブロックをブロックにグループ化します。これは他のモードと互換性がありません。

      --no-color-moved-ws

      移動検出を実行する時、空白を無視しません。これは構成設定を上書きするために使用できます--color-moved-ws=noと同じです。

      --word-diff[=<mode>]

      <mode>を使用して変更された単語を区切ることにより、単語の差分を表示します。デフォルトでは単語は空白で区切られます。以下の--word-diff-regexを参照してください。<mode>のデフォルトはプレーンで、次のいずれかである必要があります。

      color

      色のみを使用して変更された単語をハイライトします。--colorを意味します。

      plain

      単語を[-removed-]および{+added+}として表示します。区切り文字が入力に表示されている場合、区切り文字をエスケープしようとしないため、出力があいまいになる可能性があります。

      porcelain

      スクリプトの使用を目的とした特別なラインベースのフォーマットを使用します。追加/削除/変更されていない場合、通常の統一された差フォーマットで印刷され、ラインの先頭が+/- “文字で始まり、ラインの終わりまで続きます。入力の改ラインは独自のラインのチルダ~で表されます。

      none

      単語の差分を再度無効にします。

      最初のモードの名前にもかかわらず、有効になっている場合、すべてのモードで変更された部分をハイライトするために色が使用されることに注意してください。

      --word-diff-regex=<regex>

      非空白の実行を単語と見なす代わりに、<regex>を使用して単語が何であるかを決定します。また、すでに有効になっていない限り、--word-diffを意味します。

      <regex>の重複しない一致はすべて単語と見なされます。これらの一致の間のすべては空白と見なされ、違いを見つけるために「ignored(!)」とされます。正規表現に|[^[:space:]] を追加して、空白以外のすべての文字と一致することを確認することをお勧めします。改ラインを含む一致は改ラインでそのまま「truncated(!)」されます。

      例えば、--word-diff-regex=.です。各文字を単語として扱い、それに応じて、文字ごとの違いを示します。

      正規表現は差分ドライバーまたは構成オプションを介して設定することもできます。

      gitattributes[5]またはgit-config[1]を参照してください。これを指定すると差分ドライバーまたは構成設定が明示的に上書きされます。差分ドライバーは構成設定を上書きします。

      --color-words[=<regex>]

      --word-diff=color(正規表現が指定されている場合)と--word-diff-regex=<regex>と同等です。

      --no-renames

      構成ファイルにデフォルトで指定されている場合でも、名前変更の検出をオフにします。

      --[no-]rename-empty

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

      --check

      変更によってコンフリクトマーカーまたは空白エラーが発生した場合に警告します。空白エラーと見なされるものはcore.whitespace構成によってコントロールされます。デフォルトでは末尾の空白(空白のみで構成されるラインを含む)とラインの最初のインデント内で直後にタブ文字が続くスペース文字は空白エラーと見なされます。問題が見つかった場合、ゼロ以外のステータスで終了します。「–exit-code」とは互換性がありません。

      --ws-error-highlight=<kind>

      差分のContextoldnewラインにおける空白エラーをハイライトします。複数の値はコンマで区切られ、noneは前の値をリセットし、defaultはリストをnewにリセットし、allold,new,contextの省略形です。このオプションが指定されておらず、構成変数diff.wsErrorHighlightが設定されていない場合、新しいラインの空白エラーのみがハイライトされます。空白エラーはcolor.diff.whitespaceで色分けされています。

      --full-index

      パッチフォーマットの出力を作成する時、最初の文字の代わりに「インデックス」ラインにイメージ前およびイメージ後の完全なブロブオブジェクト名を表示します。

      --binary

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

      --abbrev[=<n>]

      40バイトの16進オブジェクト名全体を差分ローフォーマットの出力と差分ツリーヘッダーラインに表示する代わりに、部分的なプレフィックスのみを表示します。差分パッチ出力フォーマットでは--full-indexが優先されます。つまり--full-indexが指定されている場合、--abbrevに関係なく完全なブロブ名が表示されます。デフォルト以外の桁数は--abbrev=<n>で指定できます。

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

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

      これはファイルの完全な書き換えに相当する変更がコンテキストとしてテキストで一致する少数のラインと混合された一連の削除と挿入としてではなく、古いものすべての単一の削除とそれに続くすべての新しいものを1回挿入し、数値mは-Bオプションのこの側面をコントロールします(デフォルトは60%)。 -B/70% はGitがそれを完全な書き換えと見なすために元の30%未満が結果に残る必要があることを示します(つまり結果のパッチはコンテキストラインと混合された一連の削除と挿入になります)。

      -Mと一緒に使用すると、完全に書き換えられたファイルも名前変更のソースと見なされ(通常、-Mは消えたファイルのみを名前変更のソースと見なします)、番号nは-Bオプションのこの側面をコントロールします。(デフォルトは50%)。-B20% はファイルのサイズの20%以上と比較して、追加および削除を伴う変更が別のファイルへの名前変更の可能なソースとして取得される資格があることを指定します。

      -M[<n>]
      --find-renames[=<n>]

      差分を作成する場合、コミットごとに名前の変更を検出してレポートします。履歴をトラバースしながら名前を変更してファイルをフォローする方法については--followを参照してください。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

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

      -Bと併用する場合、削除/作成ペアの削除部分のプリイメージも省略してください。

      -l<num>

      –M-C オプションには「O(n ^ 2)」処理時間が必要です。ここでnは潜在的な名前変更/コピーターゲットの数です。このオプションは名前変更/コピーターゲットの数が指定された数を超えた場合、名前変更/コピー検出が実行されないようにします。

      --diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

      追加(A)、コピー(C)、削除(D)、変更(M)、名前変更(R)、タイプ(つまり通常のファイル、シンボリックリンク、サブモジュールなど)が変更(T)、マージされていない(U)、不明(X)、またはペアリングが壊れている(B)ファイルのみを選択します。フィルタ文字の任意の組み合わせ(なしを含む)を使用できます。*(全て、もしくはゼロ)が組み合わせに追加されると、比較の他の基準に一致するファイルがある場合、すべてのパスが選択されます。他の基準に一致するファイルがない場合、何も選択されません。

      また、これらの大文字は小文字で除外できます。例えば、--diff-filter=adは追加および削除されたパスを除外します。

      すべての差分がすべてのタイプを特徴とするわけではないことに注意してください。例えば、インデックスからワークツリーへの差分にエントリを追加することはできません(差分に含まれるパスのセットはインデックスの内容によって制限されるため)。同様にこれらのタイプの検出が無効になっている場合、コピーおよび名前変更されたエントリは表示されません。

      -S<string>

      ファイル内の指定された文字列の出現回数(つまり、追加/削除)を変更する違いを探します。スクリプト作成者が使用することを目的としています。

      コードの正確なブロック(構造体など)を探し、そのブロックが最初に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し使用して、プリイメージ内の関連あるブロックにフィードバックします。-Sやロックの最初のバージョンを取得するまで続けます。

      バイナリファイルも検索されます。

      -G<regex>

      パッチテキストに<regex>と一致する追加/削除されたラインが含まれている違いを探します。

      -S<regex> --pickaxe-regex-G<regex>,の違いを説明するため、同じファイル内で次の差分を使用してコミットすることを検討してください。

      +    return frotz(nitfol, two->ptr, 1, 0);
      ...
      -    hit = frotz(nitfol, mf2.ptr, 1, 0);
      

      git log -G"frotz\(nitfol"はこのコミットを表示しますが、git log -S"frotz\(nitfol" --pickaxe-regex は表示しません(その文字列の出現回数が変更されていないため)。

      --textが提供されていない限り、「textconv」フィルターのないバイナリファイルのパッチは無視されます。

      詳細についてはgitdiffcore[7]の「pickaxe」エントリを参照してください。

      --find-object=<object-id>

      指定されたオブジェクトの出現回数を変更する違いを探します。-Sと同様に引数だけが異なり、特定の文字列ではなく特定のオブジェクトIDを検索します。

      オブジェクトはブロブまたはサブモジュールのコミットにすることができます。これはgit-log-tオプションがツリーを検索することも意味します。

      --pickaxe-all

      –Sまたは-G が変更を検出したら、<string>の変更を含むファイルだけでなく、その変更セット内のすべての変更を表示します。

      --pickaxe-regex

      -Sに指定された<string>を一致する拡張「POSIX」正規表現として扱います。

      -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」とは一致しません。

      -R

      2つの入力を交換します。つまりインデックスまたはディスク上のファイルとツリーの内容の違いを示します。

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

      プロジェクトのサブディレクトリから実行する場合、このオプションを使用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示するように指示できます。サブディレクトリ(ベアリポジトリなど)がない場合、引数として<path>を指定することで出力を作成するサブディレクトリに名前を付けることができます。--no-relative を使用し、diff.relative構成オプションと以前の--relativeの両方を無効にすることができます。

      -a
      --text

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

      --ignore-cr-at-eol

      比較を行う時、ライン末端のキャリッジリターンを無視します。

      --ignore-space-at-eol

      EOLで空白の変更を無視します。

      -b
      --ignore-space-change

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

      -w
      --ignore-all-space

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

      --ignore-blank-lines

      ラインがすべて空白である変更は無視します。

      --inter-hunk-context=<lines>

      指定されたライン数までの差分ハンク間のコンテキストを表示し、それによって互いに近いハンクを融合します。デフォルトはdiff.interHunkContextで、「config」オプションが設定されていない場合は0となります。

      -W
      --function-context

      変化の周囲の機能全体を表示します。

      --ext-diff

      外部差分ヘルパーの実行を許可します。gitattributes[5]を使用し、外部差分ドライバーを設定する場合、このオプションをgit-log[1]およびその仲間と一緒に使用する必要があります。

      --no-ext-diff

      外部差分ドライバーを禁止します。

      --textconv
      --no-textconv

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

      --ignore-submodules[=<when>]

      差分作成のサブモジュールへの変更を無視します。<when>は「none」、「untracked」、「dirty」、または「all」のいずれかになります。これがデフォルトです。「none」を使用すると、追跡されていないファイルまたは変更されたファイルが含まれている場合、またはそのヘッドがスーパープロジェクトに記録されているコミットと異なる場合にサブモジュールが変更されたと見なされ、git-config[1] またはgitmodules[5] の「ignore」オプションの設定を上書きできます。「untracked」が使用されている場合、そしてサブモジュールは追跡されていないコンテンツのみが含まれている場合、ダーティとは見なされません(ただし、変更されたコンテンツはスキャンされます)。「dirty」を使用するとサブモジュールのワークツリーへのすべての変更が無視され、スーパープロジェクトに格納されているコミットへの変更のみが表示されます(これは1.7.0までの動作です)。「all」を使用すると、サブモジュールへのすべての変更が非表示になります。

      --src-prefix=<prefix>

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

      --dst-prefix=<prefix>

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

      --no-prefix

      送信元または宛先のプレフィックスを表示しません。

      --line-prefix=<prefix>

      出力のすべてのラインに追加のプレフィックスを付加します。

      --ita-invisible-in-index

      デフォルトでは「git add -N」によって追加されたエントリは「gitdiff」に既存の空のファイルとして表示され、「gitdiff–cached」に新しいファイルとして表示されます。このオプションを使用するとエントリは「git diff」では新しいファイルとして表示され、「gitdiff–cached」では存在しません。 このオプションは--ita-visible-in-indexで元に戻すことができます。どちらのオプションも実験的なものであり、将来削除される可能性があります。
      これらの一般的なオプションの詳細についてはgitdiffcore[7]も参照してください。

      「-p」を使用してパッチテキストを作成する

      git-diff[1]、git-log[1]、git-show[1]、git-diff-index[1]、git-diff-tree[1]、git-diff-files[1]をで実行する-pオプションはパッチテキストを作成します。GIT_EXTERNAL_DIFFGIT_DIFF_OPTS 環境変数を介してパッチテキストの作成をカスタマイズできます(git[1]を参照)。

      「-p」オプションが作成するものは従来の差分フォーマットとは少し異なります。

      1. ますは次のような「gitdiff」ヘッダーがあります。
        diff --git a/file1 b/file2
        

        名前の変更/コピーが含まれない限り、a/b/ のファイル名は同じです。特に作成または削除の場合でもa/ またはb/ファイル名の代わりに/dev/nullは使用されません。
        名前変更/コピーが含まれる場合、file1 とfile2 はそれぞれ名前変更/コピーのソースファイルの名前と名前変更/コピーが作成するファイルの名前を示します。

      2. その後、1つ以上の拡張ヘッダーラインが続きます。
        old mode <mode>
        new mode <mode>
        deleted file mode <mode>
        new file mode <mode>
        copy from <path>
        copy to <path>
        rename from <path>
        rename to <path>
        similarity index <number>
        dissimilarity index <number>
        index <hash>..<hash> <mode>
        

        ファイルモードはファイルタイプとファイル許可ビットを含む6桁の8進数として出力されます。
        拡張ヘッダーのパス名にはa/ b/ プレフィックスは含まれません。
        類似性指数は変更されていないラインのパーセンテージであり、非類似性指数は変更されたラインのパーセンテージです。これは切り捨てられた整数であり、その後にパーセント記号が続きます。 したがって100%の類似性インデックス値は2つの等しいファイル用にリザーブされていますが、100%の非類似性は古いファイルから新しいファイルへのラインがないことを意味します。
        インデックスラインには変更前後のブロブオブジェクト名が含まれます。<mode>はファイルモードが変更されない場合に含まれます。それ以外の場合、別々のラインは古いモードと新しいモードを示します。

      3. 構成変数core.quotePathで説明されているように「unusual」文字を含むパス名が引用符で囲まれます(git-config[1]を参照)。
      4. 出力内のすべてのfile1はコミット前のファイルを参照し、すべてのfile2はコミット後のファイルを参照します。各変更を各ファイルに順番に適用するのは誤りです。例えば、このパッチはaとbを交換します。
        diff --git a/a b/b
        rename from a
        rename to b
        diff --git a/b b/a
        rename from b
        rename to a
        

      結合された差分形式

      差分を作成するコマンドはマージを表示するときに-cまたは--cc オプションを使用して、結合された差分を作成できます。これはgit-diff[1]またはgit-show[1]とのマージを表示する時のデフォルトのフォーマットです。これらのコマンドのいずれかに-mオプションを指定して、マージの個々のペアレントとの差分の作成を強制できることにも注意してください。

      「結合された差分」フォーマットは次のようになります。

      diff --combined describe.c
      index fabadb8,cc95eb0..4866510
      --- a/describe.c
      +++ b/describe.c
      @@@ -98,20 -98,12 +98,20 @@@
      		return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
      	}
      
      - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
      ++static void describe(char *arg, int last_one)
      {
      +	unsigned char sha1[20];
      +	struct commit *cmit;
      	struct commit_list *list;
      	static int initialized = 0;
      	struct commit_name *n;
      
      +	if (get_sha1(arg, sha1) < 0)
      +		usage(describe_usage);
      +	cmit = lookup_commit_reference(sha1);
      +	if (!cmit)
      +		usage(describe_usage);
      +
      	if (!initialized) {
      		initialized = 1;
      		for_each_ref(get_name);
      
      1. まずは「gitdiff」ヘッダーがあり、次のようになります(-c オプションを使用した場合)。
        diff --combined file
        

        またはこのようになります(--ccオプションが使用されている場合)。

        diff --cc file
        
      2. その後、1つ以上の拡張ヘッダーラインが続きます(この例は2つのペアレントとのマージを示しています)。
        index <hash>,<hash>..<hash>
        mode <mode>,<mode>..<mode>
        new file mode <mode>
        deleted file mode <mode>,<mode>
        

        mode <mode>,<mode>..<mode>ラインは<mode>の少なくとも1つが他の<mode>と異なる場合にのみ表示されます。検出されたコンテンツの移動(名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは2つの<tree-ish>の差分で機能するように設計されており、組み合わせた差分形式では使用されません。

      3. その後、2ラインの「from-file / to-file」ヘッダーが続きます
        --- a/file
        +++ b/file
        

        従来の統合差分フォーマットの2ラインヘッダーと同様に/dev/nullは作成または削除されたファイルに通知するために使用されます。
        ただし「-combined-all-paths」オプションが指定されている場合、2ラインの「from-file / to-file」の代わりに、「N +1」ラインの「from-file / to-file」ヘッダーが取得されます。ここでNはマージコミットのペアレントの数となります。

        --- a/file
        --- a/file
        --- a/file
        +++ b/file
        

        この拡張フォーマットは名前変更またはコピー検出がアクティブな場合に役立ち、さまざまなペアレントでファイルのオリジナル名を確認できます。

      4. チャンクヘッダーのフォーマットが変更され、patch -p1に誤ってフィードされるのを防ぎます。結合された差分フォーマットはマージコミットの変更を確認するために作成されたものであり、適用するためのものではありません。この変更は拡張インデックスヘッダーの変更と似ています。
        @@@ <from-file-range> <from-file-range> <to-file-range> @@@
        

        結合された差分フォーマットのチャンクヘッダーには(ペアレントの数+ 1)@文字があります。

      従来の統合差分フォーマットとは異なり、2つのファイルAとBが-(マイナスはAに表示されますが、Bでは削除されます)、+(プラスはAでは欠落していますが、Bに追加されます)、または" "( スペースは変更なし)プレフィックスを表示します。このフォーマットは2つ以上のファイル「file1、file2、…」を1つのファイルXと比較し、Xが各「fileN」とどのように異なるかを示します。ファイルNごとに1つの列が出力ラインの前に追加され、Xのラインが出力ラインとどのように異なるかを示します。

      列Nの-文字はそのラインが「fileN」に表示されるが、結果には表示されないことを意味します。 列Nの+文字はそのラインが結果に表示され、「fileN」にそのラインがないことを意味します(つまり、そのペアレントの観点からラインが追加されたということです)。

      上記の出力例では関数のシグネチャが両方のファイルから変更されています(したがって、2つ-のfile1とfile2の両方からの削除に加えて、追加された1ラインがfile1またはfile2のどちらにも表示されないことを意味する++となります)。 また、他の8ラインはfile1と同じですが、file2には表示されません(したがって、接頭辞+が付きます)。

      git diff-tree -cで表示される場合、マージコミットのペアレントをマージ結果と比較します(つまり、file1..fileNがペアレントです)。git diff-files -cで示される場合、2つの未解決のマージペアレントをワークツリーファイルと比較します(つまり、file1はステージ2であり、別名「私たちのバージョン」となっており、file2はステージ3であり、別名「それらのバージョン」となっています)。

      git show v1.0.0
      

      タグが指すオブジェクトとともに、タグv1.0.0を表示します。

      git show v1.0.0^{tree}
      

      タグv1.0.0が指すツリーを表示します。

      git show -s --format=%s v1.0.0^{commit}
      

      タグv1.0.0が指すコミットの件名を表示します。

      git show next~10:Documentation/README
      

      nextのブランチの最後の10番目のコミットで最新のファイルDocumentation/READMEの内容を表示します。

      git show master:Makefile master:t/Makefile
      

      ブランチmasterのヘッドにある「Makefile」の内容を連結します。

      議論

      Gitはある程度文字エンコードに依存しません。

        • ブロブオブジェクトの内容は解釈されていないバイトシーケンスとなっています。コアレベルでのエンコーディング変換はありません。
        • パス名はUTF-8正規化形式Cでエンコードされます。これはツリーオブジェクト、インデックスファイル、参照名、およびコマンドライン引数、環境変数、構成ファイルのパス名に適用されます((.git/config(git-config[1]を参照、gitignore[5]、gitattributes[5]、gitmodules[5])。

      コアレベルのGitはパス名を単に非NULバイトのシーケンスとして扱い、パス名をエンコードする変換はありません(MacとWindowsを除く)。したがって、非ASCIIパス名の使用はレガシー拡張ASCIIエンコーディングを使用するプラットフォームやファイルシステムでもほとんど機能します。ただしそのようなシステムで作成されたリポジトリはUTF-8ベースのシステム(Linux、Mac、Windowsなど)では正しく機能しません。その逆も同様です。さらに多くのGitベースのツールはパス名がUTF-8であると単純に想定しており、他のエンコーディングを正しく表示できません。

      • コミットログメッセージは通常UTF-8でエンコードされますが、他の拡張ASCIIエンコードもサポートされています。これにはISO-8859-x、CP125xなどが含まれますが、UTF-16 / 32、EBCDICおよびCJKマルチバイトエンコーディング(GBK、Shift-JIS、Big5、EUC-x、CP9xxなど)は含まれません。

      コミットログメッセージをUTF-8でエンコードすることをお勧めしますが、コアとGit PorcelainはどちらもプロジェクトでUTF-8を強制しないように設計されています。特定のプロジェクトのすべての参加者がレガシーエンコーディングを使用する方が便利だと思った場合、Gitはそれを禁止しません。ただし覚えておくべきことがいくつかあります。

      1. 「gitcommit」および「gitcommit-tree」はプロジェクトでレガシーエンコーディングを使用していることを明示的に指定しない限り、与えられたコミットログメッセージが有効なUTF-8文字列のように見えない場合に警告を発行します。これを言う方法は次のように.git/configファイルに「i18n.commitencoding」を含めることです。
        [i18n]
        	commitEncoding = ISO-8859-1
        

        上記の設定で作成されたコミットオブジェクトは、encodingヘッダーにi18n.commitEncodingの値を記録します。これは後でそれらを見る他の人を助けるためです。このヘッダーがないということはコミットログメッセージがUTF-8でエンコードされていることを意味します。

      2. 「git log」、「git show」、「git blame」とその仲間たちはコミットオブジェクトのencodingヘッダーを調べ、特に指定がない限り、ログメッセージをUTF-8に再コーディングしようとします。 次のようにgit/configファイルのi18n.logOutputEncodingを使用して目的の出力エンコーディングを指定できます。
        [i18n]
        	logOutputEncoding = ISO-8859-1
        

        この構成変数がない場合、代わりにi18n.commitEncodingの値が使用されます。

      UTF-8への再コーディングは必ずしも元に戻せる操作ではないため、コミットが行われたときにコミットログメッセージを再コーディングしないことを意図的に選択したことに注意してください。

      GIT

      git[1]パッケージソフトの一部

git公式ドキュメント

show