SYNOPSIS

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

DESCRIPTION

1つまたはそれ以上のオブジェクト(ブロブ・ツリー・タグ・コミット)を表示します。

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

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

ツリーの場合は、名前が表示されます(--name-only オプション付きの git ls-tree 相当)。

プレーンブロブの場合は、プレーンコンテンツが表示されます。

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

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

OPTIONS

<object>…

表示するオブジェクトの名前(デフォルトは「HEAD」)。オブジェクト名を綴る方法のより完全なリストについては、 gitrevisions(7) の「SPECIFYING REVISIONS」セクションを参照してください。

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

コミットログの内容を指定された形式できれいに印刷(pretty-print)します。 <format> は oneline、short、medium、full、fuller、reference、email、raw、format:<string>、tformat:<string> のいずれかになります。 <format> が上記のいずれでもなく、「%プレースホルダー」が含まれている場合、 --pretty=tformat:<format> が指定されたかのように動作します。

各フォーマットの詳細については、「PRETTY FORMATS」セクションを参照してください。 =<format> の部分を省略すると、デフォルトで medium になります。

注意: リポジトリー構成でデフォルトのpretty formatを指定できます(git-config(1) 参照)。

--abbrev-commit

40バイトの16進コミットオブジェクト名全体を表示する代わりに、オブジェクトに一意の名前を付けるプレフィックスを表示します。 "--abbrev=<n>" (表示されている場合はdiff出力も変更します)オプションを使用して、プレフィックスの最小長を指定できます。

これにより、80桁幅の端末を使用している人にとって "--pretty=oneline" がずっと読みやすくなるはずです。

--no-abbrev-commit

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

--oneline

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

--encoding=<encoding>

コミットオブジェクトは、ログメッセージに使用される文字エンコードをエンコードヘッダーに記録します。このオプションを使用して、ユーザーが好むエンコーディングでコミットログメッセージを再コーディングするようにコマンドに指示できます。配管以外のコマンドの場合、これはデフォルトでUTF-8になります。オブジェクトが X でエンコードされていると主張し、 X で出力している場合、オブジェクトをそのまま出力することに注意してください。これは、元のコミットの無効なシーケンスが出力にコピーされる可能性があることを意味します。 同様に、 iconv(3) がコミットの変換に失敗した場合、 元のオブジェクトをそのまま黙って出力します。

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

出力に表示する前に、ログメッセージでタブ展開を実行します(タブ幅を <n> とみなして <n> 境界に揃うように空白で調整する)。 --expand-tabs は --expand-tabs=8 の省略形であり、 --no-expand-tabs は --expand-tabs=0 の省略形です。タブの展開を無効にします。

デフォルトでは、タブはログメッセージを4つのスペースでインデントするきれいな形式(pretty formats)で展開されます(つまり、medium (これがデフォルト) と full と fuller)。

--notes[=<ref>]

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

デフォルトでは、表示されるnotesは、 core.notesRef および notes.displayRef 変数(または対応する環境変数オーバーライド)にリストされているnote refからのものです。詳細については git-config(1) を参照してください。

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

複数の --notes オプションを組み合わせて、表示するノートを制御できます。 例: "--notes=foo" は "refs/notes/foo" からのnotesのみを表示します。 "--notes=foo --notes" は、 "refs/notes/foo" とデフォルトのnotes ref(s) の両方のnotesを表示します。

--no-notes

notesを表示しないでください。 これは、notesが表示されるnotes refのリストをリセットすることにより、上記の --notes オプションを無効にします。 オプションは、コマンドラインで指定された順序で解析されます。 "--notes --notes=foo --no-notes --notes=bar" は、 "refs/notes/bar" からのnotesのみを表示します。

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

これらのオプションは非推奨です。 代わりに、上記の --notes/--no-notes オプションを使用してください。

--show-signature

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

PRETTY FORMATS

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

いくつかの組み込みフォーマットがあります。そして以下で説明するように、 pretty.<name> 構成オプション(config option)を別のフォーマット名または format: 文字列に設定することで、追加のフォーマットを定義できます(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プレースホルダーを使用する他の 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 のどちらが使用されているかに関係なく、ハッシュは完全に表示され、「親」(parents)情報は、移植や履歴の単純化を考慮せずに、真の親のコミットを示します。この形式は、コミットの表示方法に影響しますが、いわゆる git log --raw の差分の表示方法ではありません。生のdiff形式で完全なオブジェクト名を取得するには、 --no-abbrev を使用します。

  • format:<format-string>

    format:<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

      改行(newline)

      %%

      `%`そのもの

      %x00

      16進数のバイト値を出力

    • これより後ろのプレースホルダーのフォーマッティングに影響を与えるプレースホルダー:

      %Cred

      赤色に切り替える

      %Cgreen

      緑色に切り替える

      %Cblue

      青色に切り替える。

      %Creset

      色をリセットする

      %C(...)

      git-config(1) の「CONFIGURATION FILE」の Values で説明されている色の指定。 デフォルトでは、色はログ出力が有効になっている場合にのみ表示されます(color.diff または color.ui または --color によって、ターミナルに出す場合は前者の auto 設定を尊重します)。 %C(auto,...) は、 default の歴史的同義語として受け入れられます(例: %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) ..ft 切り捨て、または 中央 (mtrunc) mi..le 切り捨て、または末尾切り捨て (trunc) rig.. ます (.. は省略符号)。 注意1: 切り捨ては N >= 2 の場合にのみ正しく機能します。 注意2: N および M (以下参照) 値の前後の空白はオプションです。 注意3: 絵文字やその他のワイド・キャラクタは表示桁を2つ必要とするため、桁の境界を超える可能性があります。 注意4: 複合文字マーク(character combining marks)が詰物境界で誤って分割配置される可能性があります。

      %<|( <M> )

      これの次のプレースホルダーが少なくとも M 桁目の表示桁までを占めるようにし、必要に応じて右側に空白を詰めます。 端末ウィンドウの右端から測定した桁位置には、負の M 値を使用して下さい。

      %>( <N> ), %>|( <M> )

      それぞれ %<( <N> ), %<|( <M> ) に似ていますが、左側に空白が埋め込まれます

      %>>( <N> ), %>>|( <M> )

      それぞれ %>( <N> ), %>|( <M> ) に似ていますが、 これに続くプレースホルダーが指定よりも多くの空白を使用し、その左側に空白がある場合は、それらの空白を使用します

      %><( <N> ), %><|( <M> )

      それぞれ %<( <N> ), %<|( <M> ) に似ていますが、 両側にパディングがあります(つまり、 テキストが中央に配置されます)

    • コミットから抽出された情報に展開するプレースホルダー:

      %H

      コミットハッシュ

      %h

      省略されたコミットハッシュ

      %T

      ツリーハッシュ

      %t

      省略されたツリーハッシュ

      %P

      親のハッシュ達

      %p

      省略された親のハッシュ達

      %an

      作者名

      %aN

      作者名( .mailmap に関しては、 git-shortlog(1) または git-blame(1) 参照)

      %ae

      作者電子メールアドレス

      %aE

      作者電子メールアドレス( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %al

      作者電子メールアドレスアカウント名(local-part)(@ の前の部分)

      %aL

      作者電子メールアカウント名(%al 参照)( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %ad

      作成日(フォーマットに関しては --date= オプション参照)

      %aD

      作成日 RFC2822形式

      %ar

      作成日 相対(relative)形式

      %at

      作成日 UNIXタイムスタンプ形式

      %ai

      作成日 ISO 8601風形式

      %aI

      作成日 厳密なISO 8601形式

      %as

      作成日 短い形式(YYYY-MM-DD)

      %ah

      作者作成日(author date)の人間が読める形式(human style)(git-rev-list(1) の ‘--date=human’ に似ている)

      %cn

      コミッター名

      %cN

      コミッター名( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %ce

      コミッター電子メールアドレス

      %cE

      コミッター電子メールアドレス( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %cl

      コミッター電子メールアドレスアカウント名(local-part)( @ の前の部分)

      %cL

      コミッター電子メールアカウント名(local-part)( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %cd

      コミッター日付(フォーマットに関しては --date= オプション参照)

      %cD

      コミッター日付 RFC2822形式

      %cr

      コミッター日付 相対(relative)形式

      %ct

      コミッター日付 UNIXタイムスタンプ形式

      %ci

      コミッター日付 ISO 8601風形式

      %cI

      コミッター日付 厳密なISO 8601形式

      %cs

      コミッター日付 短い形式(YYYY-MM-DD)

      %ch

      コミッター日付 人間が読める形式(git-rev-list(1) の --date=human に似ている)

      %d

      ref名 git-log(1) の --decorate オプションみたいなの

      %D

      " (", ")" で囲ってないref名

      %(describe[:options])

      git-describe(1) のような人間が読める名前。説明できないコミットの場合は空の文字列。 describe 文字列の後には、コロンと、0個以上のカンマで区切られたオプションを続けることができます。タグの追加や削除を同時に行うと、説明に一貫性がなくなる可能性があります。

      • tags[=<bool-value>]: 注釈付きタグ(annotated tags)だけを考慮するのではなく、軽量タグ(lightweight tags)も考慮してください。

      • abbrev=<number>: 短縮ブジェクト名のデフォルトの 16 進数の桁数 (デフォルトは 7 で、リポジトリ内のオブジェクトの数によって異なります) を使用する代わりに、 <number> 桁数を指定するか、または 一意のオブジェクト名を形成するために必要な桁数。

      • match=<pattern>: refs/tags/ プレフィックスを除いて、指定された glob(7) パターンに一致するタグのみを考慮します。

      • exclude=<pattern>: refs/tags/ プレフィックスを除いて、指定された glob(7) パターンに一致するタグを対象にしません。

      %S

      (git log --source のような、)コマンドラインで指定した、コミットに到達したref名で、 git log でのみ機能します。

      %e

      エンコーディング

      %s

      件名(subject)

      %f

      ファイル名に適した、サニタイズされた件名

      %b

      本文(body)

      %B

      生本文(raw body)(行折り曲げされてない件名と本文)

      %N

      コミットノート(commit notes)

      %GG

      署名されたコミットの為のGPGからの生の検証メッセージ

      %G?
      G

      良い(good)な(有効な)署名の場合はこの文字に置換されます。

      B

      悪い署名(bad signature)の場合はこの文字に置換されます。

      U

      有効性が不明(unknown validity)な良い署名の場合はこの文字に置換されます。

      X

      期限切れ(eXpired)の良い署名の場合はこの文字に置換されます。

      Y

      期限切れのキーで作成された良い署名の場合はこの文字に置換されます。

      R

      取り消されたキーによって作成された良い署名の場合はこの文字に置換されます。

      E

      署名を確認できない場合(キーの欠落など)の場合はこの文字に置換されます。

      N

      署名がない場合の場合はこの文字に置換されます。

      %GS

      署名されたコミットの署名者の名前を表示する

      %GK

      署名されたコミットに署名するために使用されるキーを表示する

      %GF

      署名されたコミットに署名するために使用されるキーのフィンガープリントを表示する

      %GP

      署名付きコミットの署名に使用されたサブキー(subkey)の主キー(primary key)のフィンガープリントを表示します

      %GT

      署名されたコミットに署名するために使用されるキーの信頼レベル(trust level)を表示します

      %gD

      reflog セレクター(例えば refs/stash@{1} とか refs/stash@{2 minutes ago})。 この形式は、 -g オプションで説明されている規則に従います。 @ の前の部分は、コマンドラインで指定されたrefnameです(したがって、 git log -g refs/heads/master は refs/heads/master@{0} を生成します)。

      %gd

      短縮 reflog セレクター。 %gD と同一ですが、人間が読みやすい形式でrefname部分が短縮されています(したがって、 refs/heads/master は単に master になります)。

      %gn

      reflog ID名

      %gN

      reflog ID名( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %ge

      reflog ID 電子メールアドレス

      %gE

      reflog ID 電子メールアドレス( .mailmap に関しては、git-shortlog(1) または git-blame(1) 参照)

      %gs

      reflog 件名

      %(trailers[:options])

      git-interpret-trailers(1) によって解釈されるようにボディのトレーラーを表示します。 trailers 文字列の後には、コロンと、0個以上のカンマで区切られたオプションを続けることができます。いずれかのオプションが複数回提供された場合、それぞれ最後のものが優先されます。

      • key=<key>: 指定された <key> を持つトレーラーのみを表示します。マッチングは大文字と小文字を区別せずに行われ、末尾のコロンはオプションです。オプションが複数回指定されている場合、いずれかのキーに一致するトレーラー行が表示されます。このオプションは自動的に only オプションを有効にして、トレーラーブロック内の非トレーラー行が非表示になるようにします。それが望ましくない場合は、 only=false で無効にすることができます。 たとえば、 %(trailers:key=Reviewed-by) は、キーが `Reviewed-by`のトレーラー行を表示します。

      • only[=<bool>]: トレーラーブロックに非トレーラー行を含めるかどうかを選択します。

      • separator=<sep>: トレーラー行の間に挿入される区切り文字を指定します。このオプションが指定されていない場合、各トレーラー行は改行文字で終了します。文字列 <sep> には、上記のリテラルフォーマットコードが含まれる場合があります。区切り文字としてコンマを使用するには、次のオプションとして解析されないよう %x2C を使用する必要があります。 たとえば、 %(trailers:key=Ticket,separator=%x2C ) は、キーが Ticket であるすべてのトレーラー行をカンマとスペースで区切って表示します。

      • unfold[=<bool>]: interpret-trailer の --unfold オプションが指定されたかのように動作させます。たとえば、 %(trailers:only,unfold=true) が展開され、すべてのトレーラー行が表示されます。

      • keyonly[=<bool>]: トレーラーのキー部分のみを表示。

      • valueonly[=<bool>]: トレーラーの値部分のみ表示。

      • key_value_separator=<sep>: トレーラー行の間に挿入される区切り文字を指定します。このオプションが指定されていない場合、各トレーラーのキーと値のペアは ": " で区切られます。 それ以外の場合は、上記の separator=<sep> と同じセマンティクスを共有します。

Note
 一部のプレースホルダーは、リビジョントラバーサルエンジンに指定された他のオプションに依存する場合があります。 たとえば、 %g* reflogオプションは、reflogエントリをトラバースしない限り(たとえば、 git log -g によって)空の文字列を挿入します。コマンドラインで --decorate がまだ指定されていない場合、 %d と %D プレースホルダーは「短い」(short)装飾形式を使用します。

ブール値オプションは、オプションの値 [=<bool-value>] を受け入れます。 値 true 、false 、 on 、off などはすべて受け入れられます。 git-config(1) の "EXAMPLES" の "boolean" サブセクションを参照してください。ブール値オプションが値なしで指定された場合、それは有効を指定した事になります。

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

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

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

  • tformat:

    tformat: 形式は、 "separator" セマンティクスの代わりに "terminator" セマンティクスを提供することを除いて、 format: とまったく同じように機能します。 つまり、各コミットには、エントリ間に区切り文字を配置するのではなく、メッセージターミネータ文字(通常は改行)が追加されます。 これは、「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: があるかのように解釈(interpret)されます。 たとえば、以下の2つは同等です:

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

DIFF FORMATTING

以下のオプションを使用して、 git show がdiff出力を生成する方法を変更できます。

-p
-u
--patch

パッチを生成します(セクション・タイトル "Generating patch text with -p" 参照)。

-s
--no-patch

diff 機構からの出力をすべて抑制します。 デフォルトでパッチを表示する git show のようなコマンドで出力を抑制したり、 コマンドラインのエイリアスで --patch や --stat などのオプションの効果をキャンセルしたりする場合に便利です。

--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc|remerge|r)
--no-diff-merges

マージコミットに使用するdiff形式を指定します。 --first-parent が使用されている場合を除き、デフォルトは dense-combined です。使用されている場合は、 first-parent がデフォルトです。

--diff-merges=(off|none)
--no-diff-merges

マージコミットのdiffの出力を無効にします。暗黙の値を上書きするのに便利です。

--diff-merges=on
--diff-merges=m
-m

このオプションにより、マージコミットのdiff出力がデフォルトの形式で表示されます。 -m は、 -p も指定されている場合にのみ出力を生成します。デフォルトの形式は、 log.diffMerges 構成パラメーター(configuration parameter)を使用して変更できます。デフォルト値は separate です。

--diff-merges=first-parent
--diff-merges=1

このオプションにより、マージコミットは最初の親に関してのみ完全なdiffを表示します。

--diff-merges=separate

これにより、マージコミットは各親に関して完全なdiffを表示します。親ごとに個別のログエントリとdiffが生成されます。

--diff-merges=remerge
--diff-merges=r
--remerge-diff

このオプションを使用すると、2 つの親マージ・コミットが再マージされて、一時的なツリー・オブジェクトが作成されます。 — これには、競合マーカーなどを含むファイルが含まれる可能性があります。 次に、その一時ツリーと実際のマージ・コミットの間の差分が表示されます。

このオプションが使用されたときの出力は変更される可能性があり、他のオプションとの相互作用も変更される可能性があります (明示的に文書化されていない限り)。

--diff-merges=combined
--diff-merges=c
-c

このオプションを使用すると、マージコミットのdiff出力は、親と結果のペアごとの差分を一度に1つずつ表示するのではなく、各親からの差分をマージ結果に同時に表示します。さらに、すべての親から変更されたファイルのみが一覧表示されます。 -c は -p の機能を含んでいます。

--diff-merges=dense-combined
--diff-merges=cc
--cc

このオプションを使用すると、 --diff-merges=Combined によって生成される出力は、親のコンテンツに2つの派生(variants)しかない、興味のないハンクを省略してさらに圧縮され、マージ結果は変更なしでそのうちの1つを選択します。 --cc は -p の機能を含んでいます。

--combined-all-paths

このフラグにより、結合された差分(マージコミットに使用)にすべての親からのファイルの名前が一覧表示されます。したがって、これは --diff-merges=[dense-]combined が使用されている場合にのみ有効であり、ファイル名の変更が検出された場合(つまり、名前の変更またはコピーの検出が要求された場合)にのみ役立つ可能性があります。

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

通常の3行ではなく、<n> 行の内容でdiffを生成します。 --patch の機能を含んでいます。

--output=<file>

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

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

生成されたパッチの新しい行、古い行、またはコンテキスト行を示すために使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 " " です。

--raw

コミットごとに、生の差分形式を使用して変更の概要を表示します。 git-diff(1) の "RAW OUTPUT FORMAT" セクションを参照してください。 これは、ログ自体をraw形式で表示することとは異なります。 これは --format=raw で 実現できます。

--patch-with-raw

-p --raw の同義語。

-t

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

--indent-heuristic

diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッチを読みやすくします。 これがデフォルトです。

--no-indent-heuristic

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

--minimal

より多くの時間を費やして、可能な限り最小のdiffが生成されるようにします。

--patience

"patience diff" アルゴリズムを使用してdiffを生成します。

--histogram

"histogram diff" アルゴリズムを使用してdiffを生成します。

--anchored=<text>

"anchored diff" アルゴリズムを使用してdiffを生成します。

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

行が比較元(source)と比較先(destination)の両方に存在し、かつ、1回だけ存在し、かつ、このテキストで始まる場合、このアルゴリズムは、その行が出力に削除または追加として表示されないようにします。内部で "patience diff" アルゴリズムを使用します。

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

diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

default, myers

基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、これがデフォルトです。

minimal

より多くの時間を費やして、可能な限り最小のdiffが生成されるようにします。

patience

パッチを生成する時に "patience diff" アルゴリズムを使います。

histogram

このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張して、「発生率の低い共通要素をサポート」(support low-occurrence common elements)します。

たとえば、 あなたが 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

ファイルの作成や削除( "new" または "gone" 。オプションでシンボリックリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置かれます。本機能は --stat の機能を含んでいます。

--numstat

--stat に似ていますが、プログラムで処理しやすい(machine friendly)ように、追加および削除された行数を10進表記とパス名で省略形なしで表示します。バイナリファイルの場合、 0 0 の代わりに2つの - を出力します。

--shortstat

変更されたファイルの総数と、追加および削除された行の数を含む --stat 形式の最後の行のみを出力します。

-X[<param1,param2,...>]
--dirstat[=<param1,param2,...>]

各サブディレクトリの相対的な変更量の分布を出力します。 --dirstat の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズできます。デフォルトは、 diff.dirstat 構成変数によって制御されます(git-config(1) 参照)。以下のパラメータを使用できます:

changes

比較元(source)から削除された、または比較先(destination)に追加された行をカウントして、dirstat数を計算します。これは、ファイル内の純粋なコード移動の量を無視します。つまり、ファイル内の行の再配置は、他の変更ほどカウントされません。これは、パラメーターが指定されていない場合のデフォルトの動作です。

lines

通常の行ベースのdiff分析を実行し、削除/追加された行数を合計して、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

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

--patch-with-stat

-p --stat と同義語。

-z

改行(newline)ではなく、NULでコミットを区切ります。

また、 --raw または --numstat を指定した場合は、パス名を難読化(munge)したり、出力フィールドターミネータとしてNULを使用したりしないでください。

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

--name-only

変更されたファイルの名前のみを表示します。 多くの場合、ファイル名はUTF-8でエンコードされます。 詳細については、 git-log(1) のマニュアルページにあるエンコーディングに関する議論(the discussion about encoding)を参照してください。

--name-status

変更されたファイルの名前とステータスのみを表示します。ステータス文字の意味については、 --diff-filter オプションの説明を参照してください。 --name-only と同じように、ファイル名はしばしばUTF-8でエンコードされます。

--submodule[=<format>]

サブモジュールの違いをどのように表示するかを指定します。 --submodule=short を指定する場合、 short形式が使用されます。この形式は、範囲の最初と最後にコミットの名前を表示するだけです。 --submodule または --submodule=log が指定されている場合、 log形式が使用されます。この形式では、 git-submodule(1) summary のように範囲内のコミットが一覧表示されます。 --submodule=diff が指定されている場合、 diff形式が使用されます。この形式は、コミット範囲間のサブモジュールの内容の変更のインラインdiffを示します。configオプションが設定されていない場合、デフォルトは diff.submodule または short 形式です。

--color[=<when>]

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

--no-color

カラーdiffをオフにします。 --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 に似ていますが、移動されたコードの重要でない部分の追加の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は興味深いと見なされ、残りは興味深いものではありません。 dimmed_zebra は非推奨の同義語です。

--no-color-moved

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

--color-moved-ws=<modes>

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

no

移動行検出を実行するときに、空白(whitespace)を無視しない。

ignore-space-at-eol

行末(EOL)での空白(whitespace)の変更を無視します。

ignore-space-change

空白(whitespace)の数の変更は無視してください。これは、行末の空白(whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他のすべてのシーケンスを同等と見なします。

ignore-all-space

行を比較するときは空白(whitespace)を無視します。これにより、一方の行に空白があり、もう一方の行に空白がない場合でも、違いは無視されます。

allow-indentation-change

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

--no-color-moved-ws

移動検出を実行するときは、空白(whitespace)を無視しないでください。これは、構成設定を上書きするために使用できます。 --color-moved-ws=no と同じです。

--word-diff[=<mode>]

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

color

変更された単語(word)を色のみを使用して強調表示します。 --color を意味します。

plain

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

porcelain

スクリプトの使用を目的とした特別な行ベースの形式を使用します。追加/削除/無変更については、通常の統一されたdiff形式で印刷され、行の先頭の +/-/` ` 文字で始まり、行の終わりまで続きます。入力の改行は、それ自体の行のチルダ ~ で表されます。

none

単語(word)のdiffを再度無効にします。

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

--word-diff-regex=<regex>

空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるかを決定します。また、すでに有効になっていない限り、この機能は --word-diff の機能を含んでいます。

<regex> の重複しないマッチはすべて、単語と見なされます。これらのマッチの間のすべては空白と見なされ、違いを見つけるためとしては無視されます！ 正規表現に |[^[:space:]] を追加して、空白以外のすべての文字とマッチすることを確認することをお勧めします。改行を含むマッチは、改行で黙って切り捨てられます！

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

正規表現は、diffドライバーまたは構成オプション(configuration option)を介して設定することもできます。 gitattributes(5) または git-config(1) を参照してください。これを指定すると、diffドライバーまたは構成設定(configuration settings)が明示的にオーバーライドされます。diffドライバーは構成設定を上書きします。

--color-words[=<regex>]

--word-diff=color に --word-diff-regex=<regex> を加えたものに相当します(正規表現が指定されている場合)。

--no-renames

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

--[no-]rename-empty

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

--check

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

--ws-error-highlight=<kind>

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

--full-index

パッチ形式の出力を生成するときは、最初の一握りの文字(first handful of characters)の代わりに、「インデックス」行にイメージ前およびイメージ後の完全ブロブオブジェクト名を表示します。

--binary

--full-index に加えて、 git-apply で適用できるバイナリ差分を出力します。 --patch の機能を含んでいます。

--abbrev[=<n>]

完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくとも <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッチ出力形式では、 --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>]

diffを生成する場合は、コミットごとに名前の変更を検出して報告します。 履歴をトラバースしながら名前を変更してファイルをフォローする方法については、 --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 オプションは、コピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピーを検索します。このフラグにより、コマンドは変更されていないファイルをコピー元の候補として検査します。これは大規模なプロジェクトでは非常にコストのかかる操作であるため、注意して使用してください。 複数の -C オプションを指定しても同じ効果があります。

-D
--irreversible-delete

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

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

-l<num>

-M および -C オプションには、名前変更/コピーのサブセットを安価に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペアになっていない比較先(destinations)をすべての関連ソースと比較する徹底的なフォールバック部分が続きます。(名前の変更の場合、残りのペアになっていないソースのみが関係します。コピーの場合、すべての元のソースが関係します)。N個の、ソースと比較先の場合、この徹底的なチェックのコストは O(N^2) です。このオプションは、関係するソース/比較先ファイルの数が指定された数を超えた場合に、名前変更/コピー検出の完全な部分が実行されないようにします。デフォルトは diff.renameLimit です。 値0は無制限として扱われることに注意してください。

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

追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更(Rename)されたファイル、タイプが変更されたファイル(T)、マージされていないファイル(U)、不明なファイル(X)、またはペアリングが壊れているファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合わせを使用できます。 組み合わせに * (全てまたは無し)が追加されると、比較で他の基準に一致するファイルがある場合、すべてのパスが選択されます。 他の基準に一致するファイルがない場合、何も選択されません。

また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定します。例えば --diff-filter=ad は、追加および削除されたパスを除外します。

注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意してください。 たとえば、これらのタイプの検出(detection)が無効になっている場合、コピーされたエントリと名前変更されたエントリは表示されません。

-S<string>

ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の差分を調べます。スクリプターが使用することを目的としています。

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

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

-G<regex>

パッチテキストに <regex> にマッチする 追加/削除 された行が含まれている差分を探します。

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

+    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> の変更を含むファイルだけでなく、その変更セット(changeset)のすべての変更を表示します。

--pickaxe-regex

-S に指定した <string> を拡張POSIX正規表現として扱います。

-O<orderfile>

ファイルが出力に表示される順序を制御します。これは diff.orderFile 構成変数をオーバーライドします(git-config(1) 参照)。 diff.orderFile をキャンセルするには、 -O/dev/null を使用します。

出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力され、2番目のパターンに一致する(ただし最初のパターンには一致しない)パス名を持つすべてのファイルが次に出力されます。パス名がどのパターンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一致パターンがあるかのように、最後に出力されます。複数のパス名のランクが同じである場合(同じパターンに一致するが、以前のパターンには一致しない)、相互の出力順序は通常の順序です。

<orderfile> は以下のとおりパースされます:

  • 空白行は無視されるため、読みやすくするための区切りとして使用できます。

  • ハッシュ ("#") で始まる行は無視されるため、コメントに使用できます。 パターンがハッシュで始まる場合は、パターンの先頭にバックスラッシュ(訳注:日本では環境により円記号)("\") を追加します。

  • 他の各行には、単一のパターンが含まれています。

パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパターンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポーネントをいくつも削除するとパターンと一致する場合、パス名もパターンと一致する点が異なります。 たとえば、パターン "foo*bar" は、 "fooasdfbar" および "foo/bar/baz/asdf" と一致しますが、 "foobarx" とは一致しません。

--skip-to=<file>
--rotate-to=<file>

名前付き <file> の前のファイルを出力から破棄するか(スキップして)、出力の最後に移動させます(ローテーションさせます)。 これらは主に git difftool コマンドを使用するために考案されたものであり、それ以外の場合はあまり役に立たない可能性があります。

-R

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

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

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

-a
--text

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

--ignore-cr-at-eol

比較を行うときは、行末のキャリッジリターン(carriage-return)を無視します。

--ignore-space-at-eol

行末(EOL)での空白(whitespace)の変更を無視します。

-b
--ignore-space-change

空白(whitespace)の数の変更は無視してください。これは、行末の空白(whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他のすべてのシーケンスを同等と見なします。

-w
--ignore-all-space

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

--ignore-blank-lines

全て空白の行の変更は無視します。

-I<regex>
--ignore-matching-lines=<regex>

すべての行が <regex> にマッチする変更を無視します。このオプションは複数回指定できます。

--inter-hunk-context=<lines>

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

-W
--function-context

関数全体を各変更のコンテキスト行として表示します。関数名は、 git diff がパッチハンクヘッダーを処理するのと同じ方法で決定されます(gitattributes(5) の「Defining a custom hunk-header」参照)。

--ext-diff

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

--no-ext-diff

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

--textconv
--no-textconv

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

--ignore-submodules[=<when>]

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

--src-prefix=<prefix>

"a/" の代わりに、指定した比較元プレフィックス(source prefix)を表示します。

--dst-prefix=<prefix>

"b/" の代わりに、指定した比較先プレフィックス(destination prefix)を表示します。

--no-prefix

比較元(source)または比較先(destination)のプレフィックスを表示しません。

--default-prefix

デフォルトの比較元(source)および比較先(destination)のプレフィックスを使用します("a/" と "b/")。通常、これは既にデフォルトではありますが、 diff.noprefix などの設定をオーバーライドするために使用されることがあります。

--line-prefix=<prefix>

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

--ita-invisible-in-index

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

これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照してください。

Generating patch text with -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_DIFF と GIT_DIFF_OPTS 環境変数( git(1) 参照)、および diff 属性( gitattributes(5) 参照)を介してカスタマイズできます。

-pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります: 

    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/ プレフィックスは含まれません。

    類似インデックス(similarity index)は変更されていない行のパーセンテージであり、非類似インデックス(dissimilarity index)は変更された行のパーセンテージです。これは切り捨てられた整数であり、その後にパーセント記号が続きます。したがって、100％の類似インデックス値は2つの等しいファイルを表し、100％の非類似性は古いファイルから新しいファイルに移行された行がないことを意味します。

    インデックス行には、変更前後のブロブオブジェクト名が含まれます。 <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、構成変数 core.quotePath で説明されているように引用符で囲まれています( 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

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されています。特定の言語に合わせてこれを調整する方法の詳細については、 gitattributes(5) の "Defining a custom hunk-header" を参照してください。

Combined diff format

diffを生成するコマンドは、マージを表示するときに -c または --cc オプションを使用して「合成diff」(combined diff)を生成できます。これは git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形式です。 注意: これらのコマンドのいずれかに適切な --diff-merges オプションを指定して、特定の形式で差分を強制的に生成できることにも注意してください。

合成diff形式は以下のようになります:

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. まず "git diff" ヘッダーがあり、以下のようになります( -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> のdiffで機能するように設計されており、合成diff形式では使用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます 

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

    従来の統一diff形式の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> @@@

    合成diff形式のチャンクヘッダーには親の数+1の @ 文字があります。

従来の統一diff形式とは異なり、2つのファイルAとBが、 - (マイナスはAに表示されますが、Bでは削除されます) または + (プラスはAにはありませんが、Bには追加されます)、または " "（スペースは変更なし) プレフィックスを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1, file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示します。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどのように異なるかを示します。

列Nの - 文字は、その行が fileN に表示されているが、結果には表示されていないことを意味します。 列Nの + 文字は、結果に行が表示され、 fileN にその行がないことを意味します(つまり、その親の観点から見て行が追加されたことを示す)。

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

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

EXAMPLES

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の内容を連結して表示します。

DISCUSSION

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

  • ブロブオブジェクトの内容は、解釈されていないバイトのシーケンスです。コアレベルでのエンコーディング変換はありません。

  • パス名はUTF-8正規化形式C(UTF-8 normalization form C)でエンコードされます。これは、ツリーオブジェクト、インデックスファイル、ref名、およびコマンドライン引数、環境変数、構成ファイル( .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. git commit と git commit-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

Part of the git(1) suite