Git
英語 ▾ トピック ▾ 最新バージョン ▾ git-rev-list は 2.45.0 で最後に更新されました

名前

git-rev-list - 逆時系列でコミットオブジェクトをリストします

概要

git rev-list [<options>] <commit>…​ [--] [<path>…​]

説明

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

これは集合演算と考えることができます。コマンドラインで指定されたコミットから到達可能なコミットは集合を形成し、次に先頭に`^`が付いたコミットから到達可能なコミットはその集合から差し引かれます。残りのコミットがコマンドの出力になります。他の様々なオプションとパスパラメータを使用して、結果をさらに絞り込むことができます。

したがって、次のコマンド

$ git rev-list foo bar ^baz

は、「`foo`または`bar`から到達可能だが、`baz`からは到達不可能なすべてのコミットをリストする」ことを意味します。

特別な表記「`<commit1>`..`<commit2>`」は「`^<commit1> <commit2>`」の略記として使用できます。例えば、次のいずれかを使用することができます。

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

もう一つの特別な表記は「`<commit1>`…​`<commit2>`」で、マージに役立ちます。結果として得られるコミットの集合は、2つのオペランドの対称差です。次の2つのコマンドは同等です。

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

`rev-list`は、コミットの祖先グラフの構築とトラバース機能を提供するため、必須のGitコマンドです。このため、`git bisect`や`git repack`など、様々なコマンドで使用できる多くの異なるオプションがあります。

オプション

コミットの制限

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

一般的に、より多くのオプションを使用すると出力はさらに制限されます(例:`--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>

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

--max-age=<timestamp>
--min-age=<timestamp>

コミットの出力を指定された時間範囲に制限します。

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

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

--grep-reflog=<pattern>

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

--grep=<pattern>

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

--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がそれらのサポートを有効にしてコンパイルされていない場合、このオプションを提供するとクラッシュします。

--remove-empty

指定されたパスがツリーから消滅した時点で停止します。

--merges

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

--no-merges

親コミットが2つ以上あるコミットを出力しません。これは`--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マージを返します。

`--no-min-parents`と`--no-max-parents`はこれらの制限を(制限なしに)リセットします。同等の形式は`--min-parents=0`(任意のコミットは0以上の親を持つ)と`--max-parents=-1`(負の数は上限がないことを示す)です。

--first-parent

コミットの検索において、マージコミットに遭遇した場合は、最初の親コミットのみを辿ります。このオプションは、特定のトピックブランチの進化を閲覧する際に、より良い概要を提供できます。トピックブランチへのマージは、時折上流からの最新の状態への調整に過ぎない傾向があり、このオプションを使用することで、そのようなマージによって履歴にもたらされた個々のコミットを無視できます。

--exclude-first-parent-only

除外するコミットを検索する際(^ を使用)、マージコミットに遭遇した場合は、最初の親コミットのみを辿ります。これは、任意のマージが有効なトピックブランチの変更であることを前提として、リモートブランチから分岐した時点からのトピックブランチにおける変更の集合を見つけるために使用できます。

--not

続くすべてのリビジョン指定子に対する ^ プレフィックス(またはその不存在)の意味を反転します。次の `--not` まで有効です。コマンドラインで `--stdin` の前に使用された場合、stdin を介して渡されたリビジョンは影響を受けません。逆に、標準入力から渡された場合、コマンドラインで渡されたリビジョンは影響を受けません。

--all

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

--branches[=<pattern>]

`refs/heads` 内のすべての refs が、コマンドラインに <commit> としてリストされているかのように動作します。<pattern> が指定されている場合は、指定されたシェル glob に一致するブランチに限定します。パターンに ?*、または [ がない場合、末尾に `/*` が暗黙的に追加されます。

--tags[=<pattern>]

`refs/tags` 内のすべての refs が、コマンドラインに <commit> としてリストされているかのように動作します。<pattern> が指定されている場合は、指定されたシェル glob に一致するタグに限定します。パターンに ?*、または [ がない場合、末尾に `/*` が暗黙的に追加されます。

--remotes[=<pattern>]

`refs/remotes` 内のすべての refs が、コマンドラインに <commit> としてリストされているかのように動作します。<pattern> が指定されている場合は、指定されたシェル glob に一致するリモートトラッキングブランチに限定します。パターンに ?*、または [ がない場合、末尾に `/*` が暗黙的に追加されます。

--glob=<glob-pattern>

シェル glob <glob-pattern> に一致するすべての refs が、コマンドラインに <commit> としてリストされているかのように動作します。先頭の `refs/` は、存在しない場合は自動的に追加されます。パターンに ?*、または [ がない場合、末尾に `/*` が暗黙的に追加されます。

--exclude=<glob-pattern>

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

`--branches`、`--tags`、`--remotes` に適用される場合、指定されたパターンは `refs/heads`、`refs/tags`、`refs/remotes` で始まるべきではなく、`--glob` または `--all` に適用される場合は `refs/` で始まる必要があります。末尾に `/*` を意図する場合は、明示的に指定する必要があります。

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

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

--reflog

reflog によって言及されているすべてのオブジェクトが、コマンドラインに `<commit>` としてリストされているかのように動作します。

--alternate-refs

代替リポジトリの ref tip として言及されているすべてのオブジェクトがコマンドラインにリストされているかのように動作します。代替リポジトリとは、そのオブジェクトディレクトリが `objects/info/alternates` に指定されているリポジトリのことです。含まれるオブジェクトの集合は、`core.alternateRefsCommand` などによって変更される場合があります。git-config[1] を参照してください。

--single-worktree

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

--ignore-missing

入力に無効なオブジェクト名が見つかった場合、その不正な入力が与えられていないかのように動作します。

--stdin

コマンドラインから引数を取得することに加えて、標準入力からも引数を取得します。これは、`--all` や `--glob=` などのコミットと擬似オプションを受け付けます。`--` 区切り文字が見られると、その後の入力はパスとして扱われ、結果を制限するために使用されます。標準入力から読み取られた `--not` のようなフラグは、同じ方法で渡された引数に対してのみ尊重され、後続のコマンドライン引数には影響しません。

--quiet

標準出力に何も出力しません。この形式は、主に呼び出し元が終了ステータスをテストして、オブジェクトの範囲が完全に接続されているかどうかを確認することを目的としています。出力はフォーマットする必要がないため、stdout を ` /dev/null` にリダイレクトするよりも高速です。

--disk-usage
--disk-usage=human

通常の出力は抑制され、代わりに選択されたコミットまたはオブジェクトのディスク上のストレージに使用されるバイト数の合計を出力します。これは、出力を `git cat-file --batch-check='%(objectsize:disk)'` にパイプライン処理することと同等ですが、はるかに高速です(特に `--use-bitmap-index` を使用する場合)。「ディスク上のストレージ」の意味に関する制限については、git-cat-file[1] の `CAVEATS` セクションを参照してください。オプション値 `human` を指定すると、ディスク上のストレージサイズは人間が読み取れる文字列(例:12.24 Kib、3.50 Mib)で表示されます。

--cherry-mark

`--cherry-pick` (下記参照)に似ていますが、同等のコミットを `=` でマークし、同等でないコミットを `+` でマークします。

--cherry-pick

コミットのセットが対称差で制限されている場合、「反対側」の別のコミットと同じ変更を導入するコミットを省略します。

たとえば、ブランチ `A` と `B` の 2 つがある場合、それらの片側のみにあるすべてのコミットをリストする一般的な方法は `--left-right` を使用することです(`--left-right` オプションの説明にある例を参照)。ただし、これはもう一方のブランチからチェリーピックされたコミットを表示します(たとえば、「b 上の 3 番目」はブランチ A からチェリーピックされた可能性があります)。このオプションを使用すると、そのようなコミットのペアは出力から除外されます。

--left-only
--right-only

対称差のそれぞれの側にあるコミットのみをリストします。つまり、`--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 log --cherry upstream...mybranch` と同様に、フォークされた履歴の私たちの側にあるコミットに出力を制限し、もう一方の側に適用されたコミットを `=` でマークするために役立ちます。`git cherry upstream mybranch` と似ています。

-g
--walk-reflogs

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

`--pretty` 形式が `oneline` と `reference` 以外の場合(明らかな理由から)、出力には reflog から取得された追加情報が 2 行含まれます。出力される reflog 指定子は、`ref@{<Nth>}`(ここで <Nth> は reflog の逆時間順序インデックス)または `ref@{<timestamp>}`(そのエントリの <timestamp> を使用)として表示されます。これはいくつかのルールによって決まります。

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

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

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

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

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

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

--merge

`HEAD...<other>` の範囲で競合パスに影響を与えるコミットを表示します。ここで `<other>` は `MERGE_HEAD`、`CHERRY_PICK_HEAD`、`REVERT_HEAD`、または `REBASE_HEAD` の最初の既存の擬似 ref です。インデックスにマージされていないエントリがある場合にのみ機能します。このオプションは、3 方マージからの競合を解決する際に関連するコミットを表示するために使用できます。

--boundary

除外された境界コミットを出力します。境界コミットには-が接頭辞として付加されています。

--use-bitmap-index

パックビットマップインデックス(存在する場合)を使用して、トラバーサルを高速化しようとします。--objectsでトラバースする場合、ツリーとブローブには関連付けられたパスが出力されません。

--progress=<header>

オブジェクトが処理される際に、標準エラー出力に進行状況レポートを表示します。<header>テキストは、各進行状況更新時に出力されます。

履歴の簡略化

履歴の一部、例えば特定の<path>を変更するコミットのみに関心がある場合があります。しかし、履歴の簡略化には2つの部分があり、1つはコミットの選択、もう1つは実行方法です。履歴を簡略化する方法は様々です。

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

<paths>

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

--simplify-by-decoration

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

意味のある履歴を得るために、追加のコミットが表示される場合があります。

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

デフォルトモード

ツリーの最終状態を説明する最も単純な履歴に簡略化します。最終結果が同じ場合(つまり、同じコンテンツを持つブランチのマージ)、いくつかの枝分かれを削除するため、最も単純です。

--show-pulls

デフォルトモードからのすべてのコミットに加えて、最初の親とはTREESAMEではないが、後の親とはTREESAMEであるマージコミットを含めます。このモードは、ブランチに変更を「最初に導入した」マージコミットを表示するのに役立ちます。

--full-history

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

--dense

選択されたコミットのみと、意味のある履歴を持つためにいくつかのコミットが表示されます。

--sparse

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

--simplify-merges

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

--ancestry-path[=<commit>]

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

より詳細な説明を以下に示します。

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

以下では、簡略化設定の違いを示すために、常に同じ例履歴を参照します。このコミットグラフでは、ファイル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」のみが含まれています。

  • BAと同じ変更を含みます。そのマージMは自明であり、したがってすべての親とTREESAMEです。

  • Cfooを変更しませんが、そのマージNはそれを「foobar」に変更するため、どの親ともTREESAMEではありません。

  • Dfooを「baz」に設定します。そのマージONDの文字列を「foobarbaz」に結合します。つまり、どの親ともTREESAMEではありません。

  • Equuxを「xyzzy」に変更し、そのマージPは文字列を「quux xyzzy」に結合します。POとTREESAMEですが、EとはTREESAMEではありません。

  • Xは新しいファイルsideを追加した独立したルートコミットであり、Yはそれを変更しました。YXとTREESAMEです。そのマージQsidePに追加し、QPとTREESAMEですが、YとはTREESAMEではありません。

rev-listは履歴を逆順に辿り、--full-historyと親の書き換え(--parentsまたは--children経由)が使用されているかどうかに基づいてコミットを含めたり除外したりします。以下の設定が利用可能です。

デフォルトモード

コミットは、どの親ともTREESAMEでない場合に含まれます(ただし、これは変更できます。後述の--sparseを参照)。コミットがマージであり、1つの親とTREESAMEであった場合、その親のみを辿ります。(TREESAMEの親が複数ある場合でも、そのうちの1つのみを辿ります。)それ以外の場合は、すべての親を辿ります。

その結果、次のようになります。

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

TREESAMEの親のみを辿るというルールにより、Bが完全に考慮から除外されていることに注目してください。CNを介して考慮されましたが、TREESAMEです。ルートコミットは空のツリーと比較されるため、Iは!TREESAMEです。

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

親の書き換えなしの--full-history

このモードは、1点においてデフォルトモードとは異なります。マージのすべての親を常に辿ります。1つの親とTREESAMEである場合でもそうです。マージの複数側に含まれるコミットがある場合でも、マージ自体が含まれるとは限りません。この例では、次のようになります。

	I  A  B  N  D  O  P  Q

Mは、両方の親とTREESAMEであるため除外されました。ECBはすべて辿られましたが、Bのみが!TREESAMEであったため、他のものは表示されません。

親の書き換えがない場合、コミット間の親/子の関係について話すことは実際には不可能であるため、それらを接続されていない状態で表示します。

親の書き換えを含む--full-history

通常のコミットは、!TREESAMEでない場合にのみ含まれます(ただし、これは変更できます。後述の--sparseを参照)。

マージは常に含まれます。ただし、その親リストは書き換えられます。各親に沿って、それ自体が含まれていないコミットを削除します。その結果、次のようになります。

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

上記の親の書き換えがない--full-historyと比較してください。EはTREESAMEであるため削除されましたが、Pの親リストはEの親Iを含むように書き換えられました。CN、およびXYQについても同様です。

上記の他に、TREESAMEが包含に影響するかどうかも変更できます。

--dense

辿られたコミットは、どの親ともTREESAMEでない場合に含まれます。

--sparse

辿られたすべてのコミットが含まれます。

--full-historyがない場合でも、これはマージを簡略化します。親の1つがTREESAMEの場合、その親のみを辿るため、マージの他の側は決して辿られません。

--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に対するNPQの大きな違いに注目してください。

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

  • Pの親リストからも同様にIは削除されました。Pはその後完全に削除されました。1つの親を持ち、TREESAMEであるためです。

  • Qの親リストでは、YXに簡略化されました。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の祖先であるコミットは除外します。「Dに存在しなかったものをMが持っているもの」という意味で、D以降Mに至る履歴で何が起こったかを見るのに役立ちます。この例では、結果として、AB(そしてD自体)を除くすべてのコミットになります。

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

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

D..M範囲に適用した場合、--ancestry-path=D--ancestry-pathの代わりに使用することもできますが、これは単に、より明確な表現です。

代わりに、この範囲内の特定のトピックと、そのトピックの影響を受けたすべてのコミットに関心がある場合は、そのトピックを祖先パスに含む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--'

この例では、私がfile.txtを作成し、ABXがそれぞれ異なる方法で変更したと仮定します。親コミットが1つだけのCZYfile.txtを変更しません。マージコミットMABの両方の変更を取り込むためにマージコンフリクトを解決して作成されたため、どちらともTREESAMEではありません。しかし、マージコミットRMにおけるfile.txtの内容を無視し、Xにおけるfile.txtの内容のみを採用して作成されました。そのため、RXとTREESAMEですが、MとはTREESAMEではありません。最後に、Nを作成する自然なマージ解決はRにおけるfile.txtの内容を採用することなので、NRとTREESAMEですが、CとはTREESAMEではありません。マージコミットOPはそれぞれ最初の親とTREESAMEですが、2番目の親であるZYとはTREESAMEではありません。

デフォルトモードを使用する場合、NRはどちらもTREESAMEな親を持つため、これらのエッジが辿られ、他のエッジは無視されます。結果として得られる履歴グラフは次のようになります。

	I---X

--full-historyを使用する場合、Gitはすべてのエッジを辿ります。これにより、コミットAB、およびマージMが検出されますが、マージコミットOPも検出されます。親の書き換えにより、結果として得られるグラフは次のようになります。

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

ここで、マージコミットOPは、実際にはfile.txtに変更を加えていないため、余計なノイズとなります。これらは、古いバージョンのfile.txtに基づいたトピックをマージしただけです。これは、多くの貢献者が並行して作業し、単一のトランクにトピックブランチをマージするワークフローを使用するリポジトリでよくある問題です。多くの関連のないマージが--full-historyの結果に表示されます。

--simplify-mergesオプションを使用すると、コミットOPは結果から消えます。これは、OPの書き換えられた2番目の親が最初の親から到達可能であるためです。これらのエッジが削除されると、コミットは親とTREESAMEな単一親コミットのように見えます。これはコミットNにも起こり、履歴ビューは次のようになります。

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

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

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

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

--show-pulls

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

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

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

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

--show-pulls--simplify-mergesを組み合わせると、グラフには必要な情報がすべて含まれます。

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

MRから到達可能であるため、NからMへのエッジは簡略化されています。しかし、Nは変更Rをメインブランチに「プル」したため、重要なコミットとして履歴に依然として表示されます。

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

バイセクションヘルパー

--bisect

出力は、含まれるコミットと除外されるコミットのほぼ中間にある1つのコミットオブジェクトに制限されます。不良バイセクションリファレンスrefs/bisect/badは(存在する場合)含まれるコミットに追加され、良好バイセクションリファレンスrefs/bisect/good-*は(存在する場合)除外されるコミットに追加されます。したがって、refs/bisect/にリファレンスがないと仮定すると、

	$ git rev-list --bisect foo ^bar ^baz

midpointを出力する場合、次の2つのコマンドの出力

	$ git rev-list foo ^midpoint
	$ git rev-list midpoint ^bar ^baz

の長さはほぼ同じになります。したがって、回帰を導入する変更を見つけることは、バイナリサーチに削減されます。コミットチェーンの長さが1になるまで、繰り返し新しい「midpoint」を生成してテストします。

--bisect-vars

これは--bisectと同じ計算を実行しますが、refs/bisect/のリファレンスは使用せず、シェルで評価できる準備ができたテキストを出力します。これらの行は、中間修正の名称をbisect_rev変数に割り当て、bisect_revのテスト後にテストされるコミットの予想数をbisect_nrに、bisect_revが良好である場合にテストされるコミットの予想数をbisect_goodに、bisect_revが不良である場合にテストされるコミットの予想数をbisect_badに、現在バイセクトしているコミットの数をbisect_allに割り当てます。

--bisect-all

これは、含まれるコミットと除外されるコミットの間にあるすべてのコミットオブジェクトを、含まれるコミットと除外されるコミットからの距離に従ってソートして出力します。refs/bisect/のリファレンスは使用されません。それらから最も遠いものが最初に表示されます。(これは--bisectによって表示される唯一のものです。)

これは、いくつかの理由で一部のコミットのテストを避けたい場合(たとえば、コンパイルできない場合)に、テストするのに適したコミットを選択しやすいため便利です。

このオプションは--bisect-varsと一緒に使用できます。この場合、すべてのソートされたコミットオブジェクトの後には、--bisect-varsを単独で使用した場合と同じテキストが続きます。

コミットの順序

デフォルトでは、コミットは逆の年代順に表示されます。

--date-order

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

--author-date-order

すべての子供が表示される前に親を表示しないようにしますが、それ以外の場合は作成者タイムスタンプの順序でコミットを表示します。

--topo-order

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

たとえば、次のようなコミット履歴の場合

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

数字はコミットタイムスタンプの順序を表し、--date-orderを使用するgit rev-listなどは、タイムスタンプの順序でコミットを表示します: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

表示されるように選択されたコミット(上記のコミット制限セクションを参照)を逆順に出力します。--walk-reflogsとは組み合わせられません。

オブジェクトのトラバーサル

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

--objects

リストされたコミットによって参照されるオブジェクトのオブジェクトIDを出力します。そのため、--objects foo ^barは、「コミットオブジェクトbarは持っているがfooは持っていない場合にダウンロードする必要があるすべてのオブジェクトIDを送信してください」という意味です。下記の--object-namesも参照してください。

--in-commit-order

コミットの順序でツリーIDとBLOB IDを出力します。ツリーIDとBLOB IDは、コミットによって最初に参照された後に出力されます。

--objects-edge

--objectsに似ていますが、除外されたコミットのIDも「-」文字を前に付けて出力します。これはgit-pack-objects[1]によって、「シン」パックを作成するために使用され、これらの除外されたコミットに含まれるオブジェクトに基づいて、オブジェクトをデルタイズ形式で記録し、ネットワークトラフィックを削減します。

--objects-edge-aggressive

--objects-edgeに似ていますが、より多くの時間を費やすことで、除外されたコミットを見つけるためにさらに努力します。これは、浅いリポジトリに「シン」パックを作成するために、--objects-edgeの代わりに使用されます。

--indexed-objects

インデックスで使用されるすべてのツリーとBLOBがコマンドラインにリストされているかのように振る舞います。--objectsも使用する必要があることに注意してください。

--unpacked

--objectsでのみ有効です。パックされていないオブジェクトIDを出力します。

--object-names

--objectsでのみ有効です。見つかったオブジェクトIDの名前を出力します。これはデフォルトの動作です。「名前」は各オブジェクトに対して曖昧であり、主にオブジェクトのパッキングのためのヒントとして意図されています。特に、タグ、ツリー、BLOBの名前の区別はありません。パス名は改行を削除するために変更される可能性があり、オブジェクトが異なる名前で複数回表示される場合、名前は1つだけ表示されます。

--no-object-names

--objects とともにのみ有効です。検出されたオブジェクト ID の名前は出力しません。これは --object-names の逆です。このフラグにより、git-cat-file[1] などのコマンドで出力がより容易に解析できるようになります。

--filter=<filter-spec>

--objects* のいずれかとともにのみ有効です。出力されるオブジェクトのリストからオブジェクト(通常はブロブ)を除外します。<filter-spec> は、以下のいずれかになります。

--filter=blob:none の形式では、すべてのブロブを除外します。

--filter=blob:limit=<n>[kmg] の形式では、サイズが n バイト以上(単位指定可)のブロブを除外します。n は 0 でもかまいません。サフィックス k、m、g は、KiB、MiB、GiB の単位を表すために使用できます。たとえば、blob:limit=1kblob:limit=1024 と同じです。

--filter=object:type=(tag|commit|tree|blob) の形式では、要求されたタイプ以外のすべてのオブジェクトを除外します。

--filter=sparse:oid=<blob-ish> の形式では、ブロブ(またはブロブ式)<blob-ish> に含まれるスパースチェックアウト仕様を使用して、要求された refs でのスパースチェックアウトに不要なブロブを除外します。

--filter=tree:<depth> の形式では、ルートツリーからの深さが >= <depth> であるすべてのブロブとツリーを除外します(オブジェクトがトラバースされたコミット内で複数の深さに位置する場合、最小深さ)。<depth>=0 は、コマンドライン(または --stdin が使用される場合の標準入力)で明示的に含まれていない限り、ツリーやブロブを一切含みません。<depth>=1 は、<commit> または明示的に指定されたオブジェクトから到達可能なコミットによって直接参照されるツリーとブロブのみを含みます。<depth>=2 は <depth>=1 と似ていますが、明示的に指定されたコミットまたはツリーからさらに一つレベル離れたツリーとブロブも含みます。

ファイルシステム上の任意のパスから読み込もうとする --filter=sparse:path=<path> の形式は、セキュリティ上の理由から廃止されました。

複数の --filter= フラグを指定して、フィルタを組み合わせることができます。すべてのフィルタによって受け入れられたオブジェクトのみが含まれます。

--filter=combine:<filter1>+<filter2>+…​<filterN> の形式も、複数のフィルタを組み合わせるために使用できますが、これは --filter フラグを繰り返すよりも難しく、通常は必要ありません。フィルタは + で連結され、個々のフィルタは %-エンコード(つまり URL エンコード)されます。+% 文字に加えて、以下の文字は予約されており、エンコードする必要があります。~!@#$^&*()[]{}\;",<>?'` および ASCII コードが 0x20 以下のすべての文字(スペースと改行を含む)。

その他の任意の文字もエンコードできます。たとえば、combine:tree:3+blob:nonecombine:tree%3A3+blob%3Anone は同等です。

--no-filter

以前の --filter= 引数を無効にします。

--filter-provided-objects

明示的に指定されたオブジェクトのリストをフィルタリングします。これらのオブジェクトは、フィルタに一致しなくても常に出力されます。--filter= とともにのみ有効です。

--filter-print-omitted

--filter= とともにのみ有効です。フィルタによって除外されたオブジェクトのリストを出力します。オブジェクト ID は「〜」文字で接頭辞が付けられます。

--missing=<missing-action>

将来の「部分クローン」開発に役立つデバッグオプションです。このオプションは、欠落しているオブジェクトの処理方法を指定します。

--missing=error の形式では、欠落しているオブジェクトが検出された場合に、rev-list をエラーで停止するように要求します。これがデフォルトのアクションです。

--missing=allow-any の形式では、欠落しているオブジェクトが検出された場合でも、オブジェクトのトラバースを続行できます。欠落しているオブジェクトは、結果からサイレントに省略されます。

--missing=allow-promisor の形式は allow-any と似ていますが、予期されるプロミサーの欠落オブジェクトに対してのみオブジェクトのトラバースを続行できます。予期しない欠落オブジェクトはエラーが発生します。

--missing=print の形式は allow-any と似ていますが、欠落しているオブジェクトのリストも出力します。オブジェクト ID は「?」文字で接頭辞が付けられます。

トラバースに渡されたヒントの一部が欠落している場合、それらも欠落していると見なされ、トラバースによって無視されます。ただし、それらのオブジェクト ID を取得できない場合は、エラーが発生します。

--exclude-promisor-objects

(内部使用のみ)。プロミサー境界でオブジェクトのトラバースを事前フィルタリングします。これは部分クローンで使用されます。これは、欠落しているオブジェクトに関するエラーをサイレントにするだけでなく、トラバースを制限するため、--missing=allow-promisor よりも強力です。

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

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

--do-walk

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

コミットの書式設定

これらのオプションを使用すると、git-rev-list[1] は、より専門的なコミットログツールのファミリーである git-log[1]git-show[1]、および git-whatchanged[1] と同様に動作します。

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

指定された形式でコミットログの内容を整形して出力します。ここで、<format> は、onelineshortmediumfullfullerreferenceemailrawformat:<string>、および tformat:<string> のいずれかになります。<format> が上記のいずれでもなく、%placeholder を含む場合は、--pretty=tformat:<format> が指定されたものとして動作します。

各形式に関する詳細については、「PRETTY FORMATS」セクションを参照してください。=<format> 部分が省略されている場合、デフォルトは medium になります。

注:リポジトリ設定でデフォルトの整形形式を指定できます(git-config[1] を参照)。

--abbrev-commit

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

これにより、「--pretty=oneline」は、80 カラムのターミナルを使用しているユーザーにとって、はるかに読みやすくなります。

--no-abbrev-commit

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

--oneline

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

--encoding=<encoding>

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

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

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

デフォルトでは、ログメッセージのインデントを4スペースで行う整形形式(つまり、デフォルトのmediumfull、およびfuller)でタブが展開されます。

--show-signature

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

--relative-date

--date=relative の同義語です。

--date=<format>

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

--date=relative は、現在時刻からの相対的な日付(例:「2 時間前」)を表示します。-local オプションは --date=relative には影響しません。

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

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

  • 日付と時刻の区切り文字としてスペースを使用

  • 時刻とタイムゾーンの間にスペースを使用

  • タイムゾーンの時間と分の間にコロンを使用しない

--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 オプションはエポックからの秒数(常に 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" 形式の時分秒、4 桁の年、およびタイムゾーン情報を1行で表示します(ローカルタイムゾーンが使用されている場合を除く)。例:Thu Jan 1 00:00:00 1970 +0000

--header

コミットの内容を raw 形式で出力します。各レコードは NUL 文字で区切られます。

--no-commit-header

指定したフォーマットの前に出力される"commit"を含むヘッダー行とオブジェクトIDを抑制します。これは組み込みのフォーマットには影響しません。カスタムフォーマットのみに影響します。

--commit-header

前の--no-commit-headerを上書きします。

--parents

コミットの親も出力します("commit parent…" の形式)。また、親の書き換えも有効にします。上記の *履歴の簡素化* を参照してください。

--children

コミットの子も出力します("commit child…" の形式)。また、親の書き換えも有効にします。上記の *履歴の簡素化* を参照してください。

--timestamp

コミットの生のタイムスタンプを出力します。

--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と組み合わせることはできません。

これにより、親の書き換えが有効になります。上記の *履歴の簡素化* を参照してください。

デフォルトで--topo-orderオプションが暗黙的に有効になりますが、--date-orderオプションも指定できます。

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

--graphを使用しない場合、すべての履歴ブランチがフラット化されるため、連続する2つのコミットが線形ブランチに属していないことが分かりにくくなることがあります。このオプションは、その場合にそれらの間にバリアを挿入します。<barrier>が指定されている場合、デフォルトのものとは異なる文字列が表示されます。

--count

リストされるコミットの数を示す数値を出力し、他のすべての出力を抑制します。--left-rightと一緒に使用すると、左側のコミット数と右側のコミット数をタブで区切って出力します。--cherry-markと一緒に使用すると、これらのカウントからパッチと同等のコミットを省略し、同等のコミットのカウントをタブで区切って出力します。

PRETTY FORMATS

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

いくつかの組み込みフォーマットがあり、pretty.<name>設定オプションを別のフォーマット名または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:と同様に、その出力は--decorate--walk-reflogsなどの他のオプションの影響を受けません。

  • email

    From <hash> <date>
    From: <author>
    Date: <author-date>
    Subject: [PATCH] <title-line>
    <full-commit-message>
  • mboxrd

    emailと同様ですが、コミットメッセージ内の"From "で始まる行(ゼロ個以上の">"が前に付いている場合)は">"で引用符で囲まれるため、新しいコミットの開始と混同されません。

  • raw

    rawフォーマットは、コミットオブジェクトに保存されているとおりにコミット全体を表示します。特に、--abbrevまたは--no-abbrevが使用されているかどうかに関係なく、ハッシュは完全に表示され、parents情報はグラフトや履歴の簡素化を考慮せずに真の親コミットを表示します。このフォーマットはコミットの表示方法に影響しますが、例えばgit log --rawを使用した差分の表示方法には影響しません。生の差分フォーマットで完全なオブジェクト名を取得するには、--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.<<

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

    • 1つのリテラル文字に展開されるプレースホルダー

      %n

      改行

      %%

      生の%

      %x00

      %xの後に2つの16進数の数字が続くものは、16進数の数字の値を持つバイトに置き換えられます(このドキュメントの残りの部分ではこれを「リテラルフォーマットコード」と呼びます)。

    • 以降のプレースホルダーのフォーマットに影響を与えるプレースホルダー

      %Cred

      色を赤に切り替え

      %Cgreen

      色を緑に切り替え

      %Cblue

      色を青に切り替え

      %Creset

      色のリセット

      %C(…​)

      git-config[1]の「CONFIGURATION FILE」セクションの値で説明されているように、色の指定。デフォルトでは、色はログ出力に対して有効になっている場合にのみ表示されます(color.diffcolor.ui、または--colorによって、そしてターミナルに出力する場合、前者のauto設定を尊重します)。%C(auto,...)は、デフォルトの(例:%C(auto,red))歴史的な同義語として受け入れられます。%C(always,...)を指定すると、色が他に有効になっていない場合でも色が表示されます(ただし、このフォーマットとgitが色付けする可能性のある他のものを含め、出力全体の色を有効にするには--color=alwaysを使用することを検討してください)。autoのみ(つまり%C(auto))は、色が再び切り替えられるまで、次のプレースホルダーで自動カラーリングをオンにします。

      %m

      左(<)、右(>)、または境界(-)マーク

      %w([<w>[,<i1>[,<i2>]]])

      git-shortlog[1]の-wオプションのように、改行を切り替えます。

      %<( <N> [,trunc|ltrunc|mtrunc])

      次のプレースホルダーを少なくともN列幅にするようにし、必要に応じて右側にスペースを埋め込みます。出力列数がN列より長い場合、左(ltrunc)..ft、中央(mtrunc)mi..le、または右端(trunc)rig..で省略記号..を使用してオプションで切り捨てます。注1:切り捨てはN >= 2の場合にのみ正しく機能します。注2:NとM(下記参照)の周りのスペースはオプションです。注3:絵文字やその他の幅の広い文字は2つの表示列を占め、列境界を超える可能性があります。注4:分解された文字結合マークは、パディング境界で誤った位置に配置される可能性があります。

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

      作成者メールアドレスのローカルパート(@記号の手前の部分)

      %aL

      作成者のローカルパート(%alを参照)。.mailmapを尊重、git-shortlog[1]またはgit-blame[1]を参照)

      %ad

      作成者日付(フォーマットは--date=オプションに従います)

      %aD

      作成者日付、RFC2822スタイル

      %ar

      作成者日付、相対日時

      %at

      作成者日付、UNIXタイムスタンプ

      %ai

      作成者日付、ISO 8601風フォーマット

      %aI

      作成者日付、厳密なISO 8601フォーマット

      %as

      作成者日付、短縮形式(YYYY-MM-DD

      %ah

      作成者日付、人間向けスタイル(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

      コミッターメールアドレスのローカルパート(@記号の前部分)

      %cL

      コミッターのローカルパート(%clを参照)。.mailmapを尊重します。git-shortlog[1]またはgit-blame[1]を参照)

      %cd

      コミッター日付(フォーマットは--date=オプションに従います)

      %cD

      コミッター日付、RFC2822スタイル

      %cr

      コミッター日付、相対日時

      %ct

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

      %ci

      コミッター日付、ISO 8601風フォーマット

      %cI

      コミッター日付、厳密なISO 8601フォーマット

      %cs

      コミッター日付、短縮形式(YYYY-MM-DD

      %ch

      コミッター日付、人間向けスタイル(git-rev-list[1]--date=humanオプションと同様)

      %d

      参照名(git-log[1]の--decorateオプションと同様)

      %D

      "("と")"で囲まれていない参照名。

      %(decorate[:<options>])

      カスタム装飾付きの参照名。decorate文字列の後にコロンと、0個以上のカンマ区切りのオプションを続けることができます。オプション値には、リテラルのフォーマットコードを含めることができます。カンマ(%x2C)と閉じ括弧(%x29)は、オプション構文における役割のため、これらを使用する必要があります。

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

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

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

      • pointer=<value>: 必要に応じて、HEADとその指すブランチの間に表示されます。デフォルトは" -> "です。

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

    例えば、囲み文字やタグ注釈のない装飾を、区切り文字としてスペースを使用して生成するには

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

    %(describe[:<options>])

    git-describe[1]と同様の人間が読める名前。記述できないコミットの場合は空文字列になります。describe文字列の後にコロンと、0個以上のカンマ区切りのオプションを続けることができます。タグが同時に追加または削除されると、説明に矛盾が生じる可能性があります。

    • tags[=<bool-value>]: 注釈付きタグのみを考慮する代わりに、軽量タグも考慮します。

    • abbrev=<number>: 省略されたオブジェクト名の16進数の桁数(リポジトリ内のオブジェクトの数に応じて変化し、デフォルトは7桁)をデフォルトの数を使用する代わりに、<number>桁、または一意のオブジェクト名を作成するために必要な桁数を使用します。

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

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

    %S

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

    %e

    エンコーディング

    %s

    件名

    %f

    ファイル名として適切な、サニタイズされた件名行

    %b

    本文

    %B

    生の本文(展開されていない件名と本文)

    %GG

    署名付きコミットからのGPGの生の検証メッセージ

    %G?

    有効な署名には"G"、無効な署名には"B"、有効性不明の有効な署名には"U"、期限切れの有効な署名には"X"、期限切れのキーによって作成された有効な署名には"Y"、失効したキーによって作成された有効な署名には"R"、署名をチェックできない場合(例:キーがない場合)には"E"、署名がない場合は"N"を表示します。

    %GS

    署名付きコミットの署名者の名前を表示します。

    %GK

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

    %GF

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

    %GP

    サブキーが署名付きコミットに署名するために使用されたプライマリキーのフィンガープリントを表示します。

    %GT

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

    %gD

    reflogセレクター(例:refs/stash@{1}またはrefs/stash@{2 minutes ago})。フォーマットは-gオプションで説明されているルールに従います。@記号の手前の部分は、コマンドラインで指定された参照名です(そのため、git log -g refs/heads/masterrefs/heads/master@{0}になります)。

    %gd

    短縮されたreflogセレクター。%gDと同じですが、参照名部分は人間の可読性のために短縮されます(そのため、refs/heads/mastermasterになります)。

    %gn

    reflog識別名

    %gN

    reflog識別名(.mailmapを尊重します。git-shortlog[1]またはgit-blame[1]を参照)

    %ge

    reflog識別メールアドレス

    %gE

    reflog識別メールアドレス(.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>と同じセマンティクスを共有します。

注記
一部のプレースホルダーは、リビジョン走査エンジンに指定された他のオプションに依存する場合があります。例えば、%g* reflogオプションは、reflogエントリを走査する場合(例:git log -g)を除き、空文字列を挿入します。%d%Dプレースホルダーは、コマンドラインで--decorateが既に提供されていない場合、「short」装飾形式を使用します。

ブール型オプションは、オプションの値[=<bool-value>]を受け付けます。truefalseonoffなどはすべて受け付けられます。git-config[1]の「EXAMPLES」の「boolean」サブセクションを参照してください。値を指定せずにブール型オプションが指定されている場合、有効になります。

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

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

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

  • tformat

    tformat:フォーマットはformat:とまったく同じように動作しますが、「セパレーター」セマンティクスではなく「ターミネーター」セマンティクスを提供します。つまり、各コミットにはメッセージの終端文字(通常は改行)が追加され、エントリ間にセパレーターが配置されることはありません。これは、1行形式の最後のエントリが、「oneline」形式と同様に、改行で適切に終了することを意味します。例:

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

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

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

GIT

git[1] スイートの一部

scroll-to-top