SYNOPSIS

git log [<options>] [<revision-range>] [[--] <path>…]

DESCRIPTION

コミットのログを表示します。

指定されたコミットから「親」リンクをたどることによって到達可能なコミットをリストしますが、その前に ^ が付いているコミットから到達可能なコミットは除外します。デフォルトでは、出力は時系列の逆順で表示されます。

これは集合演算と考えることができます。 コマンドラインで指定されたコミットのいずれかから到達可能なコミットのセットを形成し、 ^ が前に付いたコミットのいずれかから到達可能なコミットがそのセットから差し引かれます。差し引かれた残りのコミットは、コマンドの出力に出力されるものです。他のさまざまなオプションとパス・パラメータ(pahts parameters)を使用して、結果をさらに制限できます。

したがって、以下のコマンド:

$ git log foo bar ^baz

は、「foo または bar から到達可能であるが、 baz からは到達できないすべてのコミットをリストする」を意味します。

特別な表記 <commit1>..<commit2> は、 ^<commit1> <commit2> の省略形として使用できます。たとえば、以下のどちらかを同じ意味で使用できます:

$ git log origin..HEAD
$ git log HEAD ^origin

もう1つの特別な表記法は、マージに役立つ <commit1>...<commit2> です。結果として得られるコミットのセットは、2つのオペランド間の対称差(symmetric difference)です。以下の2つのコマンドは同等です:

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

このコマンドは、 git-rev-list(1) コマンドに適用可能なオプションを使用して、表示内容と方法を制御し、そして git-diff(1) コマンドに適用可能なオプションを使用して、各コミットによって導入される変更の表示方法を制御します。

OPTIONS

--follow

ファイル名が途中でリネームされていてもそこで中断することなく、そのファイルの一覧を続けて表示します(単一のファイルに対してのみ機能します)。

--no-decorate
--decorate[=short|full|auto|no]

表示されているコミットのref名を出力します。 short が指定されている場合、ref名の接頭辞 refs/heads/ と refs/tags/ と refs/remotes/ は出力されません。 full が指定されている場合、完全なref名(接頭辞を含む)が出力されます。 auto が指定されている場合、出力が端末に送られると、ref名は short が指定されているかのように表示され、それ以外の場合はref名は表示されません。オプション --decorate は --decorate=short の省略形です。 log.decorate 構成値が設定されている場合はその値がデフォルトになり、 構成値が設定されていない場合は auto になります。

--decorate-refs=<pattern>
--decorate-refs-exclude=<pattern>

候補ごとに、--decorate-refs-exclude に指定されたパターンのいずれにもマッチしない場合、または --decorate-refs に指定されたパターンのいずれにもマッチしない場合は、装飾に使用しないでください。 log.excludeDecoration 構成オプションを使用すると、装飾からrefを除外できますが、明示的な --decorate-refs パターンは log.excludeDecoration のマッチングをオーバーライドします。

これらのオプションまたは構成設定のいずれも指定されていない場合、参照が HEAD または refs/heads/ または refs/remotes/ または refs/stash/ または refs/tags/ にマッチする場合、参照は装飾(decoration)として使用されます。

--clear-decorations

このオプションを指定すると、以前のすべての --decorate-refs または --decorate-refs-exclude オプションがクリアされ、すべての参照が含まれるようにデフォルトの装飾(decoration)フィルタが緩和されます。 このオプションは、構成値 log.initialDecorationSet が all に設定されている場合は前提として適用されています(This option is assumed)。

--source

各コミットがコマンドラインで指定のコミットのいずれかから到達できる祖先である場合、当該コミット毎にコマンドラインで指定のコミットのref名で表示します。

--[no-]mailmap
--[no-]use-mailmap

mailmapファイルを使用して、作者名(author names)とコミッター名(committer names)と電子メールアドレス(email addresses)を、正式な本名と電子メールアドレスにマップします。 git-shortlog(1) 参照。

--full-diff

このフラグがない場合、 git log -p <path>... は、指定されたパスに関連(touch)するコミットを示し、その指定されたパスについての差分を取ります。これにより、指定されたパスに関連するコミットの完全な差分が表示されます。これは、 "<path>…" がコミットのみを制限し、それらのコミットの差分を制限しないことを意味します。

これは、例えば --stat によって生成されたものなど、すべての差分ベースの出力タイプに影響することに注意してください。

--log-size

各コミットの出力に “log size <number>” という行を含めます。ここで、 <number> はそのコミットのメッセージの長さ(バイト単位)です。プログラムがスペースをコミットのメッセージ読み込み前に割り当てられるようにして、 git log 出力からログメッセージを読み取るツールを高速化することを目的としています。

-L<start>,<end>:<file>
-L:<funcname>:<file>

<file> 内で、 <start>,<end> または正規表現の関数名 <funcname> で指定された行範囲をトレースします。 pathspec リミッターを指定することはできません。 これは現在、 単一のリビジョンから開始するウォークに制限されています。 つまり、 0個または1個の正のリビジョン引数のみを指定でき、 <start> と <end> (または <funcname>) が開始リビジョンに存在する必要があります。 このオプションは複数回指定できます。 これは --patch オプションの機能を含んでいます。 パッチ出力は --no-patch を使用して抑制できますが、 他の diff 形式(つまり、 --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check)は現在実装されていません。

<start> と <end> は、以下のいずれかの形式です:

  • 数値

    <start> または <end> が数値の場合、絶対行番号を指定します(行は1から数えます)。

  • /regex/

    この形式は、指定されたPOSIX正規表現に一致する最初の行を使用します。 <start> が正規表現の場合、前の -L 範囲の末尾から検索します。それ以外の場合は、ファイルの先頭から検索します。 <start> が ^/regex/ の場合、ファイルの先頭から検索します。 <end> が正規表現の場合、 <start> で指定された行から検索開始します。

  • +offset or -offset

    これは <end> に対してのみ有効であり、 <start> で指定された行の前後の行数を指定します。

<start> と <end> の代わりに :<funcname> が指定されている場合、これは <funcname> に一致する最初の関数名行から次の関数名行までの範囲を示す正規表現です。 :<funcname> は、前の -L 範囲の末尾から検索します。それ以外の場合は、ファイルの先頭から検索します。 ^:<funcname> はファイルの先頭から検索します。関数名は、 git diff がパッチ・ハンク・ヘッダーを処理するのと同じ方法で決定されます(gitattributes(5) の「Defining a custom hunk-header」参照)。

<revision-range>

指定されたリビジョン範囲のコミットのみを表示します。 <revision-range> が指定されていない場合、デフォルトで HEAD (つまり、現在のコミットにつながる履歴全体)になります。 origin..HEAD は、現在のコミット(つまり、HEAD)から到達可能なすべてのコミットを指定しますが、origin からは指定しません。 <revision-range> の綴り方の完全なリストについては、 gitrevisions(7) の「Specifying Ranges」節を参照してください。

[--] <path>...

指定されたパスに一致するファイルがどのようになったかを説明するのに必要十分なコミットのみを表示します。詳細およびその他の簡略化モードについては、以下の「History Simplification」を参照してください。

混乱が生じた場合、パスをオプションまたはリビジョン範囲から分離するために、パスの前に -- を付ける必要がある場合があります。

Commit Limiting

ここで説明されている特別な表記法を使用してリストする必要があるコミットの範囲を指定することに加えて、追加のコミット制限が適用される場合があります。

より多くのオプションを使用すると、通常、出力がさらに制限されます(たとえば、 --since=<date1> は <date1> より新しいコミットに制限され、 --grep=<pattern> と一緒に使用すると、ログメッセージに <pattern> と一致する行があるコミットにさらに制限されます)。

注意: これらは、 --reverse などのコミット順序およびフォーマットオプションの前に適用されることに注意してください。

-<number>
-n <number>
--max-count=<number>

出力するコミットの数を制限します。

--skip=<number>

コミット出力の表示を開始する前に、number 個のコミットをスキップします。

--since=<date>
--after=<date>

指定の日付よりも新しいコミットを表示します。

--since-as-filter=<date>

特定の日付より新しいすべてのコミットを表示します。 これは、特定の日付より古い最初のコミットで停止するのではなく、範囲内のすべてのコミットを訪問します。

--until=<date>
--before=<date>

指定の日付より古いコミットを表示します。

--author=<pattern>
--committer=<pattern>

コミット出力を、指定されたパターン(正規表現)に一致する作者(author)/コミッター(committer)ヘッダー行を持つものに制限します。複数の --author=<pattern> がある場合、作者が指定されたパターンのいずれかに一致するコミットが選択されます(複数の --committer=<pattern> の場合も同様)。

--grep-reflog=<pattern>

コミット出力を、 指定されたパターン(正規表現)に一致するreflogエントリを持つものに制限します。 複数の --grep-reflog を使用すると、 指定されたパターンのいずれかに一致するreflogメッセージを持つコミットが選択されます。 --walk-reflogs が使用されていない限り、 このオプションを使用するとエラーになります。

--grep=<pattern>

コミット出力を、 指定されたパターン(正規表現)にマッチする単一のログメッセージを持つモノに制限します。 複数の --grep=<pattern> を使用すると、 指定されたパターンのいずれかにメッセージがマッチするコミットが選択されます(全てにマッチするコミットだけを選択したい場合、--all-match を参照してください)。

--notes が有効な場合、ノートからのメッセージは、ログメッセージの一部であるかのようにマッチングされます。

--all-match

コミット出力を、少なくとも1つに一致するものではなく、指定されたすべての --grep に一致するものに制限します。

--invert-grep

コミット出力を、 --grep=<pattern> で指定されたパターンとマッチしない単一のログメッセージを持つモノに制限します。

-i
--regexp-ignore-case

大文字小文字に関係なく、正規表現の制限パターンに一致します。

--basic-regexp

制限パターンを基本正規表現として扱います。これがデフォルトです。

-E
--extended-regexp

制限パターンを、デフォルトの基本正規表現の代わりに拡張正規表現として扱います。

-F
--fixed-strings

制限パターンを固定文字列として扱います(パターンを正規表現として解釈しないでください)。

-P
--perl-regexp

制限パターンをPerl互換の正規表現として扱います。

これらのタイプの正規表現のサポートは、コンパイル時オプションに依存します。Gitが当該のサポート付きでコンパイルされていない場合、このオプションを使うと、Gitが終了(die)します。

--remove-empty

指定されたパスがツリーから見えなくなったら停止(stop)します。

--merges

マージコミットのみを出力します。これは --min-parents=2 とまったく同じです。

--no-merges

複数の親を持つコミットを出力しない。これは --max-parents=1 とまったく同じです。

--min-parents=<number>
--max-parents=<number>
--no-min-parents
--no-max-parents

量の多少に関わらず、 とにかく複数の親コミットがあるコミットのみを表示します。特に、 --max-parents=1 は --no-merges と同じであり、 --min-parents=2 は --merges と同じです。 --max-parents=0 はすべてのルートコミットを提供し、 --min-parents=3 はすべてのタコ足マージ(octopus merges)を示します。

--no-min-parents と --no-max-parents は、これらの制限を(制限なしに)再度リセットします。同等の形式は、 --min-parents=0 (すべてのコミットに0個以上の親があります)および --max-parents=-1 (マイナスの数は上限がないことを示します)です。

--first-parent

インクルードするコミットを探すとき、マージ・コミットの最初の親コミットのみをたどります。 このオプションは、特定のトピックブランチの進化を表示するときに、より良い概要を提供できます。トピックブランチへのマージは、時々更新されるアップストリームに調整することだけである傾向があり、このオプションを使用すると、そのようなマージによって履歴に取り込まれた個々のコミットを無視できます。

このオプションは、マージコミットのデフォルトのdiff形式も first-parent に変更します。詳細については、 --diff-merges=first-parent を参照してください。

--exclude-first-parent-only

( ^ を使用して)除外するコミットを見つけるときは、 判明したマージ・コミットの最初の親コミットのみに従います。 任意のマージが有効なトピック・ブランチの変更になる可能性がある場合、 これを使用して、 リモート・ブランチから分岐したポイントからトピック・ブランチ内の一連の変更を見つけることができます。

--not

次の --not までの後続のすべてのリビジョン指定子について、 ^ プレフィックス(またはその欠落)の意味を反転します。 コマンドラインで --stdin より前で使用すると、 stdin を介して渡されたリビジョンは影響を受けません。 逆に、 標準入力経由で渡された場合、 コマンドラインで渡されたリビジョンは影響を受けません。

--all

refs/ 内のすべてのrefが HEAD とともに、コマンドラインに <commit> としてリストされているかのように見せかけます。

--branches[=<pattern>]

refs/heads 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合、ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--tags[=<pattern>]

refs/tags 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合は、指定されたシェルグロブ(shell glob)に一致するタグにタグを制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--remotes[=<pattern>]

refs/remotes 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合、リモート追跡ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--glob=<glob-pattern>

シェルグロブ <glob-pattern> に一致するすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。先頭の refs/ は、欠落している場合は自動的に先頭に追加されます。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--exclude=<glob-pattern>

次の --all または --branches または --tags または --remotes または --glob が別の方法で考慮する <glob-pattern> に一致するrefを含めないでください。このオプションを繰り返すと、次の --all または --branches または --tags または --remotes または --glob オプションまで除外パターンが蓄積されます(他のオプションまたは引数は、蓄積されたパターンをクリアしません)。

与えられたパターンは、それぞれ --branches または --tags または --remotes に適用される場合、 refs/heads または refs/tags または refs/remotes で始まるべきではありません。 --glob または --all に適用する場合は、 refs/ で始める必要があります。末尾の "/*" を意図している場合は、明示的に指定する必要があります。

--exclude-hidden=[fetch|receive|uploadpack]

transfer.hideRefs とともに適切な fetch.hideRefs 設定または receive.hideRefs 設定または uploadpack.hideRefs 設定を参照して、 git-fetch または git-receive-pack または git-upload-pack によって非表示になるrefを含めないでください(git-config(1) 参照)。 このオプションはそれ以降疑似参照オプション --all または --glob に影響し、 それらの処理後にクリアされます。

--reflog

reflogsで言及されているすべてのオブジェクトがコマンドラインに <commit> としてリストされているかのように見せかけます。

--alternate-refs

代替リポジトリのref先端として言及されているすべてのオブジェクトがコマンドラインにリストされているかのように見せかけます。 代替リポジトリは、 オブジェクトディレクトリが objects/info/alternates で指定されているリポジトリです。 インクルードされたオブジェクトのセットは、 core.alternateRefsCommand などによって変更できます。 git-config(1)を参照してください。

--single-worktree

デフォルトでは、 作業ツリーが複数ある場合、 --all と --reflog と --indexed-objects では、 すべての作業ツリーが検査されます(git-worktree(1)を参照)。 このオプションは、 現在の作業ツリーのみを調べるように強制します。

--ignore-missing

入力に無効なオブジェクト名が含まれている場合、そもそもその不正な入力が行われていないかのように見せかけます。

--bisect

コマンドラインで、bad bisection ref refs/bisect/bad がリストされ、その後に --not と good bisection ref refs/bisect/good-* が続くかのように見せかけます。

--stdin

コマンドラインから引数を取得するだけでなく、 標準入力からも引数を読み込みます。 これはコミットや、--all や --glob= のような疑似オプションを受け付けます。 -- 区切り文字が現れた場合、 それに以降の入力はパス(paths)として扱われ、 出力結果を制限するために使用されます。 標準入力経由で読み取られる --not のようなフラグは、 同一のやり方である標準入力経由で読み取られて渡された引数に対してのみ考慮され、 --stdin の後ろに置いたコマンド・ライン引数には影響しません。

--cherry-mark

--cherry-pick（以下を参照）と同様ですが、同等のコミットを省略せずに = と印し、同等でないコミットを + と印します。

--cherry-pick

コミットの組を対称差(symmetric difference)に制限する場合、「反対側」の別のコミットと同じ変更を導入するコミットを省略します。

たとえば、A と B の2つのブランチがある場合、それらの片側だけですべてのコミットを一覧表示する通常の方法は、 --left-right を使用することです(--left-right オプションの説明の以下の例を参照してください)。ただし、他のブランチからは(ブランチAと重複しない)厳選されたコミットが表示されます(たとえば、「3rd onb」はブランチAからチェリーピックされる可能性があります)。このオプションを使用すると、そのようなコミットのペアは出力から除外されます。

--left-only
--right-only

リストは、 対称差のそれぞれの側でのみコミットします。 つまり、 --left-right で < と印されるのだけか、あるいは --left-right で > と印されるものだけです。

たとえば、 --cherry-pick --right-only A…B は、 A にある、 または A のコミットとパッチと同等のコミットを B から省略します。 つまり、 これは git cherry A B からの + コミットをリストします。 より正確に書くと、 --cherry-pick --right-only --no-merges により正確なリストを提供します。

--cherry

--right-only --cherry-mark --no-merges の同義語です。 出力を私たちの側のコミットに制限し、 フォークされた履歴の反対の側に適用されたものを、 git cherry upstream mybranch と同様に git log --cherry upstream…mybranch でマークするのに役立ちます。

-g
--walk-reflogs

コミットの祖先チェーンをたどる代わりに、 reflogエントリを最新のものから古いものに移動します。 このオプションを使用する場合、 除外するコミットを指定することはできません(つまり、 ^commit や commit1..commit2 や commit1...commit2 表記は使用できません)。

(明らかな理由で、) oneline と reference 以外の --pretty 形式では、 これにより、 出力にreflogから取得された2行の追加情報が含まれます。 出力のreflog指定子は、 ref@{<Nth>} ( <Nth> はreflogの逆時系列インデックス(reverse-chronological index)) または ref@{<timestamp>} (そのエントリを <timestamp> 付で)として表示されます。 表示は下記のいくつかのルールに依存します:

  1. 開始点が ref@{<Nth>} として指定されている場合は、 インデックス形式を表示します。

  2. 開始点が ref@{now} として指定されている場合は、タイムスタンプ形式を表示します。

  3. 上記のどちらも使用されていないが、コマンドラインで --date が指定されている場合は、 --date で要求された形式でタイムスタンプを表示します。

  4. それ以外の場合は、インデックス形式を表示します。

--pretty = oneline では、コミットメッセージの前にこの情報が同じ行に付けられます。このオプションを --reverse と組み合わせることはできません。 git-reflog(1)も参照してください。

--pretty=reference では、この情報はまったく表示されません。

--merge

範囲 HEAD…<other> 内の競合したパスに触れる(touch)コミットを表示します。 ここで、<other> は MERGE_HEAD または CHERRY_PICK_HEAD または REVERT_HEAD または REBASE_HEAD のいずれかの最初の既存の擬似ref(pseudoref)です。 インデックスにマージされていないエントリがある場合にのみ機能します。 このオプションを使用すると、 三者間マージからの競合を解決するときに関連するコミットを表示できます。

--boundary

除外された境界コミットを出力します。 境界コミットの前には - が付いています。

History Simplification

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があります。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つはコミットの選択であり、もう1つはそれを行う方法です。

以下のオプションは、表示するコミットを選択します:

<paths>

<paths> で指定したパスを変更するコミットが選択されます。

--simplify-by-decoration

いくつかのブランチまたはタグによって参照されるコミットが選択されます。

注意: 意味のある重要な履歴のために、追加のコミットを表示できることに注意してください。

以下のオプションは、簡略化の実行方法に影響します。

デフォルト・モード

(以下を指定しない時のデフォルトのモード)履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最終結果が同じである場合(つまり、同じコンテンツのブランチをマージする場合)、いくつかの傍流ブランチ(side branches)を削除するため、最も単純です。

--show-pulls

デフォルト・モードからのすべてのコミットを含めますが、最初の親へのTREESAMEではなく、後の親へのTREESAMEであるマージ・コミットも含めます。このモードは、ブランチに変更を「最初に導入した」マージ・コミットを表示するのに役立ちます。(訳注:TREESAME=pathspecが全く同一であるツリー)

--full-history

デフォルト・モードと同じですが、一部の履歴を削除しません。

--dense

選択したコミットのみが表示され、重大で意味のある履歴を持つコミットもいくつか表示されます。

--sparse

簡略化された履歴内のすべてのコミットが表示されます。

--simplify-merges

このマージに寄与する選択されたコミットがないため、結果の履歴からいくつかの不要なマージを削除するための --full-history への追加オプション。

--ancestry-path[=<commit>]

表示するコミットの範囲を指定すると(例: commit1..commit2 または commit2 ^commit1)、その範囲内で <commit> の祖先、<commit> の子孫、または <commit> 自身であるコミットのみを表示します。 コミットが指定されていない場合は、commit1 (範囲の除外部分) を <commit> として使用します。 複数回渡すことができます。 その場合、あるコミットが指定されたコミットのいずれかであるか、それらのいずれかの祖先または子孫である場合、そのコミットは含まれます。

より詳細な説明は以下のとおりです。

<paths> として foo を指定したとします。 foo を変更するコミットを !TREESAME と呼び、 それ以外のコミットを TREESAME と呼びます。 ( foo でフィルタリングされた差分では、それぞれ異なって見えたりたり同じに見えたりします。）

以下、簡略化設定の違いを説明するために、同じ履歴例を使います。このコミットグラフでは、ファイル foo をフィルタリングしていると想定しています:

          .-A---M---N---O---P---Q
         /     /   /   /   /   /
        I     B   C   D   E   Y
         \   /   /   /   /   /
          `-------------'   X

履歴 A---Q の水平線は、各マージの最初の親と見なされます。その各コミットは以下のとおりです:

  • I は最初のコミットであり、ファイル foo が内容 “asdf” で存在し、ファイル quux は内容 “quux” で存在します。最初のコミットは空のツリーと比較されるため、I は !TREESAME です。

  • A では、 foo には “foo” だけが含まれています。

  • B には A と同じ変更が含まれています。 よって、 そのマージ M は些細(trivial)なことであり、 したがって、 その全ての親に対して TREESAME です。

  • C は foo を変更しませんが、そのマージ N は foo を “foobar” に変更するので、 どの親に対しても TREESAME ではありません。

  • D は foo を “baz” に設定します。そのマージ O は、 N と D から “foobarbaz” への文字列を結合します。 つまり、どの親に対しても TREESAME ではありません。

  • E は quux を “xyzzy” に変更し、そのマージ P は文字列を “quuxxyzzy” に結合します。 P は O に対して TREESAME ですが、 E に対してはそうではありません。

  • X は、新ファイル side を追加し、 Y がそれを変更した独立したルートコミットです。 Y は X へのTREESAMEです。そのマージ Q は P に side を追加し、 Q は P にはTREESAMEですが、Y に対してはそうではありません。

rev-list は、 --full-history および/または、( --parents または --children を介して)親の書き換えが使用されているかどうかに基づいて、コミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下の設定が可能です。

デフォルト・モード

(以下を指定しない場合のデフォルトのモード)コミットは、どの親に対してもTREESAMEでない場合に含まれます(これは変更できますが、以下の --sparse を参照してください)。コミットがマージであり、一方の親に対するTREESAMEであった場合は、その親のみをフォローします。(TREESAMEの親が複数ある場合でも、そのうちの1つだけをフォローします)。それ以外の場合は、すべての親をフォローします。

これにより、以下のようになります:

          .-A---N---O
         /     /   /
        I---------D

TREESAMEの親のみに従うルールが利用可能な場合は、 B を検討対象から完全に削除したことに注意してください。 C は N を介して考慮されましたが、しかしそれはTREESAMEです。ルートコミットは空のツリーと比較されるため、 I は !TREESAME です。

親子関係は --parents でのみ表示されますが、デフォルト・モードで選択されたコミットには影響しないため、親の行を示しました。

--full-history without parent rewriting

このモードはデフォルト・モードとはある一点で異なります：マージのすべての親を常に追跡する点です。 たとえそれが親の1つに対して TREESAME であってもです。 マージの複数の側に含まれるコミットがあったとしても、 それはマージ自体が含まれていることを意味するわけではありません。 この例では以下のようになります 

        I  A  B  N  D  O  P  Q

M は、両方の親にとってTREESAMEであるため、除外されました。 E と C と B をすべて巡りましたが、 そのうちの B だけが !TREESAME だったので、 それ以外の E と C は表示されません。

注意: 親の書き換え(rewrite)がないと、コミット間の親子関係について話す(talk)ことは実際には不可能であるため、それらが切断されている(disconnected)ことを示していることに注意してください。

--full-history with parent rewriting

通常のコミットは !TREESAME の場合にのみ含まれます(これは変更できますが、以下の --sparse を参照してください)。

マージは常に含まれます。ただし、親リストは書き直されます。各親に沿って、自身が含まれていないコミットを削除します。 これにより以下のようになります

          .-A---M---N---O---P---Q
         /     /   /   /   /
        I     B   /   D   /
         \   /   /   /   /
          `-------------'

これを書き直し無しの --full-history と比較してください。 E は TREESAME であるため削除されましたが、 Pの親リストは E の親 I を含むように書き直されていることに注意してください。 C と N および X と Y と Q についても同じことが起こりました。

上記の設定に加えて、あなたはTREESAMEが包含に影響を与えるかどうかを変更できます:

--dense

巡ったコミットは、親にとってTREESAMEでない場合に含まれます。

--sparse

巡ったすべてのコミットが含まれます。

--full-history がなくても、これによりマージが単純化されることに注意してください。親の1つがTREESAMEの場合、その1つだけに従うため、マージの反対側を巡ることはありません。

--simplify-merges

最初に、親を書き換えた --full-history と同じ方法で履歴グラフを作成します(上記を参照)。

それから、以下のルールに従って、各コミット C を最終履歴内の置換 C' に単純化します:

  • C' を C にセットします。

  • C' の各親 P をその簡略化された P' に置き換えます。その過程で、他の親の祖先であるか、ルートである親を削除すると、TREESAMEが空のツリーにコミットされ、重複が削除されますが、TREESAMEであるすべての親を削除しないように注意してください。

  • この親の書き換え後、 C' がルートまたはマージコミット(0または >1 の親を持つ)、境界コミット、または !TREESAMEである場合、それは残ります。それ以外の場合は、唯一の親に置き換えられます。

この効果は、親の書き換えを使用した --full-history と比較することで最もよく示されます。例は以下のようになります:

          .-A---M---N---O
         /     /       /
        I     B       D
         \   /       /
          `---------'

注意: --full-history に対する N と P と Q の主な違いに注意してください:

  • N の親リストは、他の親 M の祖先であるため、 I が削除されました。それでも、 !TREESAME なので N が残りました。

  • P の親リストも同様に I が削除されました。 P は、親が1つで TREESAMEであるため、完全に削除されました。

  • Q の親リストでは、 Y が X に簡略化されていました。その後、 X はTREESAMEルートであったため、削除されました。 Q は、親が1つで TREESAMEであるため、完全に削除されました。

利用可能な別の簡略化モードがあります:

--ancestry-path[=<commit>]

表示されるコミットを <commit> の祖先、または <commit> の子孫、または <commit> 自身に制限します。

ユースケースの例として、以下のコミット履歴について考えます:

            D---E-------F
           /     \       \
          B---C---G---H---I---J
         /                     \
        A-------K---------------L--M

通常の D..M は、 M の祖先であるコミットのセットを計算しますが、 D の祖先であるコミットは除外します。 これは、「 M には D には存在しなかったものがある」という意味で、 D 以降の M に至るまでの歴史に何が起こったのかを知るのに役立ちます。この例の結果は、 A と B (そしてもちろん D 自体)を除くすべてのコミットになります。

ただし、 M のコミットが D で入ったバグで汚染されており、修正が必要な場合は、実際には D の子孫である D..M のサブセットのみを表示する必要があります。つまり、 C と K を除外します。これはまさに --ancestry-path オプションが行うことです。これを D..M 範囲に適用すると、以下のようになります:

                E-------F
                 \       \
                  G---H---I---J
                               \
                                L--M

--ancestry-path の代わりに --ancestry-path=D を使用することもできます。これは、D..M 範囲に適用された場合と同じことを意味しますが、より明示的です。

代わりに、この範囲内の特定のトピックに関心があり、そのトピックによって影響を受けるすべてのコミットに関心がある場合、祖先パスにそのトピックを含む D..M のサブセットのみを表示したい場合があります。 たとえば、--ancestry-path=H D..M を使用すると、以下のようになります:

                E
                 \
                  G---H---I---J
                               \
                                L--M

一方、--ancestry-path=K D..M は以下のようになります

                K---------------L--M

別のオプション --show-pulls について説明する前に、新しいサンプル履歴を作成する必要があります。

簡略化された履歴を見るときにユーザーが直面する一般的な問題は、ファイルを変更したことがわかっているコミットが、ファイルの簡略化された履歴に表示されないことです。そこで、新しい例を示し、その場合に --full-history や --simplify-merges などのオプションがどのように機能するかを示しましょう。

          .-A---M-----C--N---O---P
         /     / \  \  \/   /   /
        I     B   \  R-'`-Z'   /
         \   /     \/         /
          \ /      /\        /
           `---X--'  `---Y--'

この例では、 I が file.txt を作成し、それが A と`B` と X にてさまざまな方法で変更されたとします。ひとり親のコミット C と Z と Y は file.txt を変更していません。マージコミット M は、マージの競合を解決して、 A と B の両方の変更を含めることによって作成されたため、どちらにもTREESAMEではありません。ただし、マージコミット R は、 M の file.txt の内容を無視し、 X の file.txt の内容のみを取得することによって作成されました。 したがって、 R は X へのTREESAMEですが、 M はそうではありません。最後に、 N を作成するための自然なマージ解決は、 R で file.txt の内容を取得することです。したがって、 N は C ではなく R へのTREESAMEです。マージコミット O と P は、最初の親にはTREESAMEですが、2番目の親である Z と Y にはついてはそうではありません。

デフォルト・モードを使用する場合、 N と R は両方ともTREESAMEの親を持っているため、 TREESAMEの親へ向かう経路(edges)はウォークされ、 それ以外のTREESAMEでない経路は無視されます。 結果の履歴グラフは以下のとおりです:

        I---X

--full-history を使用する場合、Gitはすべての経路(edge)を巡ります。これにより、コミット A と B と マージ M が検出されますが、マージコミット O と P も明らかになります。 親を書き換えると、結果のグラフは以下のようになります:

          .-A---M--------N---O---P
         /     / \  \  \/   /   /
        I     B   \  R-'`--'   /
         \   /     \/         /
          \ /      /\        /
           `---X--'  `------'

ここで、マージコミット O と P は、実際には file.txt への変更を提供しなかったため、余分なノイズを提供します。古いバージョンの file.txt に基づいたトピックのみをマージしました。これは、多くの寄稿者が並行して作業し、トピックブランチを単一のトランクに沿ってマージするワークフローを使用するリポジトリの一般的な問題です。 --full-history の結果には、関連のない多くのマージが表示されます。

--simplify-merges オプションを使用すると、コミット O と P が結果から消えます。 これは、 O と P の書き直された2番目の親が、最初の親から到達可能であるためです。これらの経路(edges)が削除されると、コミットは、親にとってTREESAMEである単一の親のコミットのように見えます。これはコミット N にも発生し、以下のような履歴ビューが表示されます:

          .-A---M--.
         /     /    \
        I     B      R
         \   /      /
          \ /      /
           `---X--'

このビューでは、 A と B と X からの重要なひとり親の変更がすべて表示されます。また、慎重に解決されたマージ M とそれほど慎重に解決されていないマージ R も表示されます。これは通常、コミット A と B がデフォルトのビューの履歴から「消えた」理由を判断するのに十分な情報です。ただし、このアプローチにはいくつかの問題があります。

最初の問題はパフォーマンスです。以前のオプションとは異なり、 --simplify-merges オプションでは、単一の結果を返す前にコミット履歴全体をウォークする必要があります。これにより、非常に大規模なリポジトリでこのオプションを使用するのが難しくなる可能性があります。

2番目の問題は監査に関するものです。 多くの寄稿者が同じリポジトリで作業している場合、 どのマージ・コミットが重要なブランチに変更を導入したかが重要です。 上記の問題のあるマージ R は、 重要なブランチにマージするために使用されたマージ・コミットではない可能性が高いです。 代わりに、 R と X を重要なブランチにマージするためにマージ N が使われました。 このコミットのコミット・メッセージには、 なぜ変更 X が A と B からの変更を上書きするようになった理由に関する情報が含まれている可能性があります。

--show-pulls

デフォルトの履歴に表示されるコミットに加えて、最初の親にはTREESAMEではなく、後の親にはTREESAMEである各マージコミットを表示します。

マージコミットが --show-pulls に含まれている場合、マージは別のブランチから変更を「プル」したかのように扱われます。この例で --show-pulls を使用すると(他のオプションは使用しない場合、)結果のグラフは以下のようになります:

        I---X---R---N

ここで、コミット X と R をそれぞれベースブランチにプルしたため、マージコミット R と N が含まれています。これらのマージは、コミット A と B がデフォルトの履歴に表示されない理由です。

--show-pulls が --simplify-merges とペアになっている場合、グラフには必要なすべての情報が含まれます:

          .-A---M--.   N
         /     /    \ /
        I     B      R
         \   /      /
          \ /      /
           `---X--'

M は R から到達可能であるため、 N から M への経路(edge)が単純化されていることに注意してください。ただし、 N は、変更 R をメインブランチに「プル」したため、重要なコミットとして履歴に表示されます。

--simplify-by-decoration オプションを使用すると、タグで参照されていないコミットを省略して、履歴のトポロジの全体像のみを表示できます。コミットは、(1)タグによって参照されている場合、または (2)コマンドラインで指定されたパスの内容を変更した場合に、!TREESAMEとしてマークされます(つまり、上記の履歴簡略化ルールの後に保持されます)。他のすべてのコミットはTREESAMEとしてマークされます(簡略化される可能性があります)。

Commit Ordering

デフォルトでは、コミットは新しい順に表示されます。

--date-order

すべての子が表示されるまで親を表示しませんが、それ以外の場合はコミットタイムスタンプの順序でコミットを表示します。

--author-date-order

すべての子が表示されるまで親を表示しませんが、それ以外の場合は、作者(author)のタイムスタンプ順にコミットを表示します。

--topo-order

すべての子が表示されるまで親を表示せず、複数の履歴行が混在するコミットを表示しないようにします。

たとえば、以下のようなコミット履歴があります:

    ---1----2----4----7
        \              \
         3----5----6----8---

ここで、数字はコミットタイムスタンプの順序を示し、 gitrev-list と --date-order のある友達は、タイムスタンプの順序でコミットを示します。つまり、8 7 6 5 4 3 2 1

--topo-order を使用すると、8 6 5 3 7 4 2 1（または8 7 4 2 6 5 3 1）が表示されます。2つの並列開発トラックからのコミットが混在して表示されないようにするために、いくつかの古いコミットが新しいコミットの前に表示されます。

--reverse

表示するように選択したコミットを逆の順序で出力します(上記の Commit Limiting 節を参照)。 --walk-reflogs と組み合わせることはできません。

Object Traversal

これらのオプションは、主にGitリポジトリのパッキングを対象としています。

--no-walk[=(sorted|unsorted)]

指定されたコミットのみを表示し、祖先をトラバースしない。範囲が指定されている場合、これは効果がありません。引数 unsorted が指定されている場合、コミットはコマンドラインで指定された順序で表示されます。それ以外の場合( sorted または引数が指定されていない場合)、コミットはコミット時間の逆順に表示されます。 --graph と組み合わせることはできません。

--do-walk

以前の --no-walk を上書きします。

Commit Formatting

--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=foo --notes は、 refs/notes/foo とデフォルトの ノート ref の両方のノートを表示します。

--no-notes

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

--show-notes-by-default

特定のノートを表示するオプションが指定されていない限り、 デフォルトのノートを表示します。

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

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

--show-signature

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

--relative-date

--date=relative と同じ。

--date=<format>

--pretty を使用する場合など、人間が読める形式で表示される日付に対してのみ有効になります。 log.date 構成変数(config variable)は、logコマンドの --date オプションのデフォルト値を設定します。デフォルトでは、日付は元のタイムゾーン(コミッターの、または作者のいずれか)で表示されます。 書式に -local が追加されている場合(例: iso-local )、代わりにユーザーのローカルタイムゾーンが使用されます。

--date=relative は、現在の時刻を基準にした日付を示します。例: “2 hours ago” 。 -local オプションは --date=relative には効果がありません。

--date=local は --date=default-local のエイリアスです。

--date=iso (または --date=iso8601 )は、タイムスタンプをISO 8601のような形式で表示します。厳密なISO 8601形式との違いは以下のとおりです:

  • T 日付/時刻区切り文字の代わりにスペース

  • 時間とタイムゾーンの間のスペース

  • タイムゾーンの時間と分の間にコロンがありません

--date=iso-strict (または --date=iso8601-strict )は、タイムスタンプを厳密なISO 8601形式で表示します。

--date=rfc (または --date=rfc2822 )は、RFC 2822形式のタイムスタンプを示します。これは、電子メールメッセージでよく見られます。

--date=short は、日付のみを表示し、時刻は表示せず、 YYYY-MM-DD 形式で表示します。

--date=raw は、エポック(1970-01-01 00:00:00 UTC)からの秒数、スペース、UTCからのオフセット(+ または - の付いた4桁数字で、最初の2つは時間、次の2つは分です)。つまり、タイムスタンプが strftime("%s %z") でフォーマットされているかのようになります。 -local オプションは、seconds-since-epoch値(常にUTCで測定されます)には影響しませんが、付随するタイムゾーン値を切り替えることに注意してください。

--date=human は、タイムゾーンが現在のタイムゾーンと一致しない場合はタイムゾーンを表示し、一致する場合は日付全体を出力しません(つまり、「今年」の日付の場合は年の出力をスキップしますが、何があったか覚えてるような過去数日については日付自体もスキップします)。 古い日付の場合、時と分も省略されます。

--date=unix は、日付をUnixエポックタイムスタンプ(1970年からの秒数)として表示します。 --raw と同様に、これは常にUTCであるため、 -local は効果がありません。

--date=format:... は、内部で処理される%sと%zと%Zを除いて、フォーマット ... をあなたのシステムの strftime に送ります。 --date=format:%c を使用して、システムロケールの推奨形式で日付を表示します。フォーマットプレースホルダーの完全なリストについては、 strftime マニュアルを参照してください。 -local を使用する場合、正しい構文は --date=format-local:... です。

--date=default はデフォルトの形式であり、 ctime(3) の出力に基づいています。これは 3文字の曜日と、3文字の月と、日付と、「HH:MM:SS」形式の時分秒が 1 ​​行に表示され、 その後に 4 桁の年と、ローカルタイムゾーンが使用されている場合を除きタイムゾーン情報が続きます。例: Thu Jan 1 00:00:00 1970 +0000

--parents

コミットの親も出力します( "commit parent…" の形式で)。親の書き換えも可能にします。上記「History Simplification」を参照してください。

--children

コミットの子も出力します( "commit child…" の形式で)。親の書き換えも可能にします。上記「History Simplification」を参照してください。

--left-right

対称差のどちら側からコミットに到達できるかをマークします。左側からのコミットには < が付けられ、右側からのコミットには > が付けられます。 --boundary と組み合わせると、それらのコミットの前に - が付きます。

たとえば、以下のトポロジーの場合:

             y---b---b  branch B
            / \ /
           /   .
          /   / \
         o---x---a---a  branch A

以下のような出力が得られます:

        $ git rev-list --left-right --boundary --pretty=oneline A...B

        >bbbbbbb... 3rd on b
        >bbbbbbb... 2nd on b
        <aaaaaaa... 3rd on a
        <aaaaaaa... 2nd on a
        -yyyyyyy... 1st on b
        -xxxxxxx... 1st on a
--graph

出力の左側に、コミット履歴のテキストベースのグラフィック表現を描画します。グラフ履歴を適切に描画するために、コミットの間に余分な行が出力される可能性があります。 --no-walk と組み合わせることはできません。

これにより、親の書き換えが可能になります。上記「History Simplification」を参照してください。

これは、デフォルトで --topo-order オプションを意味しますが、 --date-order オプションも指定できます。

--show-linear-break[=<barrier>]

--graph を使用しない場合、すべての履歴ブランチがフラット化されるため、2つの連続するコミットが線形ブランチに属していないことがわかりにくくなる可能性があります。このオプションは、その場合、それらの間に障壁(barrier)を置きます。 <barrier> が指定されている場合、デフォルトの障壁文字列の代わりに <barrier> が表示されます。

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

      %x に続く2桁の16進数は、 その値を持つバイトに置き換えられます(このドキュメントでは、 これを「リテラル書式設定コード」(literal formatting code)と呼びます)。

    • 後続のプレースホルダーの書式設定に影響を与えるプレースホルダー達:

      %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名

      %(decorate[:<options>])

      カスタム装飾が施された ref 名。 decorate 文字列の後には、 コロン(":")と 0 個以上のカンマ(",")区切りのオプション達が続く場合があります。 オプション値にカンマ(",")や閉じ丸括弧(")")自体を含める場合は、 それぞれリテラル書式設定コードの %x2C (コンマ)や %x29 (閉じ丸括弧) を使用する必要があります。

      • prefix=<value>: ref 名のリストの前に表示されます。 デフォルトは " (" です。

      • suffix=<value>: ref 名のリストの後に表示されます。 デフォルトは ")" です。

      • separator=<value>: ref 名と ref 名の間に表示されます。 デフォルトは ", " です。

      • pointer=<value>: (存在する場合、) HEAD とそれが指すブランチの間に表示されます。 デフォルトは " -> " です。

      • tag=<value>: タグ名の前に表示されます。 デフォルトは "tag: " です。

      たとえば、 行ラッピングやタグ注釈を使用せず、 区切り文字としてスペースを使用して装飾を作成するには、 以下のようにします:

      %(decorate:prefix=,suffix=,tag=,separator= )

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

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

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

      • separator=<sep>: トレーラー行の間に挿入される区切り文字を指定します。 デフォルトはLFです。 文字列 <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" サブセクションを参照してください。ブール値オプションが値なしで指定された場合、それは有効(enabled)になります。

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

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

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

  • 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 log はdiff出力を生成しません。以下のオプションを使用して、各コミットによって行われた変更を表示できます。

注意: --diff-merges のバリエーション(短い -m, -c, --cc, --dd オプションを含む)の1つが明示的に指定されていない限り、マージ・コミットは diff を表示しませんし、 --patch のような diff 書式が選択されていても、 -S のような検索オプションとも一致しません。 例外は、 --first-parent が使用されている場合です。 この場合、 first-parent がマージ・コミットのデフォルトの書式です。

-p
-u
--patch

パッチを生成します([generate_patch_text_with_p] 参照)。

-s
--no-patch

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

-m

マージ・コミットの diff をデフォルト形式で表示します。 これは --diff-merges=on に似ていますが、 -m は -p も指定しない限り出力を生成しません。

-c

マージ・コミットの結合された diff 出力(combined diff output)を生成します。 --diff-merges=combined -p のショートカットです。

--cc

マージ・コミット用に高密度に結合された diff 出力を生成します。 --diff-merges=dense-combined -p のショートカットです。

--dd

マージと通常のコミットの両方について、 最初の親に関する diff を生成します。 --diff-merges=first-parent -p のショートカットです。

--remerge-diff

マージ・コミットの remerge-diff 出力を生成します。 --diff-merges=remerge -p のショートカットです。

--no-diff-merges

--diff-merges=off の同義語。

--diff-merges=<format>

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

以下の形式がサポートされています:

off, none

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

on, m

マージ・コミットがデフォルト形式で表示されるように diff 出力を作成します。 デフォルトの形式は、 log.diffMerges 設定変数を使用して変更でき、 そのデフォルト値は separate です。

first-parent, 1

最初の親に関する完全な diff を表示します。 これは、 非マージ・コミットに対して --patch が生成するものと同じ形式です。

separate

各親に関する完全な diff を表示します。 親ごとに個別のログ・エントリと diff が生成されます。

combined, c

親と結果の間のペアごとの diff を一度に 1 つずつ表示するのではなく、 各親からマージ結果までの diff を同時に表示します。 さらに、 すべての親から変更されたファイルのみがリストされます。

dense-combined, cc

--diff-merges=combined によって生成される出力をさらに圧縮するために、 親の内容が2つのバリエーションしかなく、 マージ結果がそのうちの1つを変更せずに選択する、 興味深いとは言えないハンクを省略します。

remerge, r

2 つの親のマージ・コミットを再マージして一時なツリー・オブジェクトを作成します。 このオブジェクトには、 競合マーカーなどを持つファイルが含まれる可能性があります。

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

--combined-all-paths

結合された diff (combined diffs)(マージコミットに使用)に、 すべての親からのファイルの名前がリストされます。 したがって、これは --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回だけ存在し、かつ、 <text> で始まる場合、このアルゴリズムは、その行が出力に削除または追加として表示されないようにします。内部で「patience diff」アルゴリズムを使用します。

--diff-algorithm=(patience|minimal|histogram|myers)

diffアルゴリズムを選択します。そのバリエーションは以下のとおりです:

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> を指定するか、または diff.statNameWidth=<name-width> を設定することによって制限できます。 グラフ部分の幅は、 --stat-graph-width=<graph-width> を使用するか、 または diff.statGraphWidth=<graph-width> を設定することによって制限できます。 --stat または --stat-graph-width の使用は統計グラフを生成するすべてのコマンドに影響しますが、 diff.statNameWidth または diff.statGraphWidth の設定は 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 [<param>,...]
--dirstat[=<param>,...]

各サブディレクトリの相対的な変更量の分布を出力します。 --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[=<param>,...]

--dirstat=files,<param>,... と同義語。

--summary

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

--patch-with-stat

-p --stat と同義語。

-z

コミットは改行ではなく「NUL」で区切ります。

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

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

--name-only

ポスト・イメージ・ツリー(post-image tree)に、 変更された各ファイルの名前のみを表示します。 多くの場合、ファイル名は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=<mode>,...

これは、 --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>]

デフォルトでは、単語は空白(whitespace)で区切られます。 以下の --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>

ファイル内の指定の <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=<number>

指定された行数までの差分ハンク間のコンテキストを表示し、それによって互いに近いハンクを融合します。デフォルトは 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[=(none|untracked|dirty|all)]

diff 生成時にサブモジュールへの変更を無視します。 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 や diff.srcPrefix や diff.dstPrefix や diff.mnemonicPrefix などの設定をオーバーライドします(git-config(1) 参照)。

--line-prefix=<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>

    ファイルモード(<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 log --no-merges

コミット履歴全体を表示しますが、マージはスキップします

git log v2.6.12.. include/scsi drivers/scsi

バージョン v2.6.12 以降で include/scsi または drivers/scsi サブディレクトリ内のファイルの変更がある、すべてのコミットを表示します

git log --since="2 weeks ago" -- gitk

gitk ファイルの変更について過去2週間の範囲で表示します。 -- は「ブランチ名のgitk」と混同しないようにするために必要です。

git log --name-status release..test

「test」ブランチにはあるがまだ「release」ブランチにはないコミットを、各コミットが変更するパスのリストとともに表示します。

git log --follow builtin/rev-list.c

ファイルに現在の名前が付けられる前に発生したコミット(訳注:つまりファイル名が変更される前の当該ファイル)を含め、builtin/rev-list.c を変更したコミットを表示します。

git log --branches --not --remotes=origin

ローカルブランチ origin にあり、 origin のリモート追跡ブランチのいずれにも存在していないコミットを表示します。

git log master --not --remotes=*/master

ローカルmasterにはあるが、リモートリポジトリmasterブランチにはないすべてのコミットを表示します。

git log -p -m --first-parent

変更の差分を含む履歴を表示しますが、「主ブランチ」の観点からのみ、マージされたブランチからのコミットをスキップし、マージによって導入された変更の完全な差分を表示します。これは、単一の統合ブランチにとどまり、そのブランチにすべてのトピックブランチをマージするという厳格なポリシーに従う場合にのみ意味があります。

git log -L '/int main/',/^}/:main.c

ファイル main.c の関数 main() が時間の経過とともにどのように進化したかを示します。

git log -3

表示するコミットの数を3個に制限します。

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への再コーディングは必ずしも可逆的な操作ではないため、我々はコミットが行われたときにコミットログメッセージを再コーディングしないことを意図的に選択したことに注意してください。

CONFIGURATION

コア変数については git-config(1) を、diff生成に関連する設定については git-diff(1) を参照してください。

format.pretty

--format オプションのデフォルト。(上記「Pretty Formats」を参照してください。)デフォルトは medium です。

i18n.logOutputEncoding

ログを表示するときに使用するエンコーディング。(上記「Discussion」を参照してください。)デフォルトでは、設定されている場合は i18n.commitEncoding の値になり、そうでない場合は UTF-8 になります。

このセクションのこの行より上にあるものはすべて、 git-config(1) ドキュメントには含まれていません。 以下の内容に関しては、git-config(1) ドキュメント にあるものと同一です。

log.abbrevCommit

trueの場合、 linkgit:git-log [1] と git-show(1) と git-whatchanged(1) に --abbrev-commit を想定させます。 このオプションは --no-abbrev-commit で上書きできます。

log.date

log コマンドのデフォルトの日時モードを設定します。 log.dateの値の設定は、 git log の --date オプションと同様です。 詳細については、 git-log(1) を参照してください。

形式が auto:foo に設定されていて、 ページャーが使用されている場合、 形式 foo が日付形式に使用されます。 それ以外の場合は、 default が使用されます。

log.decorate

logコマンドで表示されるコミットのref名を出力します。 short が指定されている場合、ref名の接頭辞 refs/heads/ と refs/tags/ と refs/remotes/ は出力されません。 full が指定されている場合、完全なref名(接頭辞を含む)が出力されます。 auto が指定されている場合、出力が端末に送られる場合、ref名は short が指定されているかのように表示されます。それ以外の場合、ref名は表示されません。 これは、 git log の --decorate オプションと同じです。

log.initialDecorationSet

デフォルトでは、 git log は特定の既知の ref 名前空間の装飾(decorations)のみを表示します。 all が指定されている場合は、すべてのrefを装飾として表示します。

log.excludeDecoration

ログ装飾(log decorations)から指定されたパターンを除外します。 これは --decorate-refs-exclude コマンドラインオプションに似ていますが、構成オプションは --decorate-refs オプションで上書きできます。

log.diffMerges

--diff-merges=on が指定されたときに使用される diff 形式を設定します。 詳細については、git-log(1) の --diff-merges を参照してください。 デフォルトは separate です。

log.follow

true の場合、 git log は、単一の<path>が指定されたときに --follow オプションが使用されたかのように機能します。 これには --follow と同じ制限があります。つまり、複数のファイルを追跡するために使用することはできず、非線形履歴ではうまく機能しません。

log.graphColors

git log --graph で履歴線(history lines)を描画するために使用できる、コンマで区切られた色のリスト。

log.showRoot

trueの場合、最初のコミットは大きな作成イベントとして表示されます。 これは、空のツリーに対するdiffに相当します。 git-log(1) や git-whatchanged(1) などのツールは、通常はルートコミットを隠していますが、今後は表示されるようになります。 デフォルトでは True です。

log.showSignature

trueの場合、 git-log(1) と git-show(1) と git-whatchanged(1) に --show-signature を想定させます。

log.mailmap

trueの場合、 git-log(1) と git-show(1) と git-whatchanged(1) で --use-mailmap を想定させ、それ以外の場合は --no-use-mailmap を想定させます。 デフォルトではtrueです。

notes.mergeStrategy

ノートの競合を解決するときにデフォルトで選択するマージ戦略。 manual 、` ours`、 theirs、` union` 、cat_sort_uniq のいずれかである必要があります。 デフォルトは manual です。 各戦略の詳細については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを参照してください。

この設定は、 --strategy オプションを git-notes(1) に渡すことでオーバーライドできます。

notes.<name>.mergeStrategy

refs/notes/<name> にノートをマージするときに、どのマージ戦略を選択するか。 これは、より一般的な notes.mergeStrategy をオーバーライドします。 利用可能な戦略の詳細については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを参照してください。

notes.displayRef

git log 系のコマンドでコミット・メッセージを表示する際に、 core.notesRef や GIT_NOTES_REF で設定したデフォルトに加えて、どのref (グロブ、または複数回指定されている場合は複数ref)からノートを読み込むかを指定します。

この設定は、 GIT_NOTES_DISPLAY_REF 環境変数でオーバーライドでき、環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要があります。

存在しないrefsに対しては警告が発行されますが、どのrefsにもマッチしないグロブは黙って無視されます。

この設定は、コマンドの git log 系の --no-notes オプション、またはこれらのコマンドで受け入れられる --notes=<ref> オプションによって無効にすることができます。

core.notesRef の有効な値(GIT_NOTES_REFによってオーバーライドされる可能性があります)も、表示されるrefのリストに暗黙的に追加されます。

notes.rewrite.<command>

<command> (現在は amend または rebase)でコミットを書き換え、 そして、 この変数が false に設定されている場合、git はノートを元のコミットから書き換えられたコミットにコピーしません。 デフォルトは true です。 下記 notes.rewriteRef も参照してください。

この設定は、 GIT_NOTES_REWRITE_REF 環境変数でオーバーライドでき、環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要があります。

notes.rewriteMode

書き換え時にノートをコピーする場合(notes.rewrite.<command> オプション参照)、ターゲットコミットにすでにノートがある場合の対処方法を決定します。 overwrite 、 concatenate 、 cat_sort_uniq 、 ignore のいずれかである必要があります。 デフォルトは concatenate です。

この設定は、 GIT_NOTES_REWRITE_MODE 環境変数でオーバーライドできます。

notes.rewriteRef

書き換え中にノートをコピーする場合は、ノートをコピーする(完全修飾された)refを指定します。 グロブと見なしたら、マッチするすべてのrefのノートがコピーされます。 この構成を複数回指定することもできます。

デフォルト値はありません。 ノートの書き換えを有効にするには、この変数を構成する必要があります。 デフォルトのコミットノートの書き換えを有効にするには、これを refs/notes/commits に設定します。

GIT_NOTES_REWRITE_REF 環境変数でオーバーライドできます。 その形式の詳細については、上記 notes.rewrite.<command> を参照してください。

GIT

Part of the git(1) suite