SYNOPSIS

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

DESCRIPTION

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

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

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

$ git rev-list foo bar ^baz

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

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

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

もう1つの特別な表記法は、マージに役立つ <commit1>...<commit2> です。結果として得られるコミットのセットは、2つのオペランド間の対称差(symmetric difference)です。以下の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 などのさまざまなコマンドで使用できる多くのオプションがあります。

OPTIONS

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>

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

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

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

--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 を参照してください)。

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

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

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

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

--stdin

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

--quiet

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

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

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

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

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

--use-bitmap-index

(使用可能な場合は、)パックビットマップインデックスを使用して、トラバーサルを高速化しようと試みます。 --objects でトラバースする場合、ツリーとブロブには関連するパスが出力されないことに注意してください。

--progress=<header>

オブジェクトが対象になるたびに、 stderrに進捗レポートを出力します。 進行状況が更新されるたびに <header> テキストが出力されます。

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としてマークされます(簡略化される可能性があります)。

Bisection Helpers

--bisect

含まれるコミットと除外されるコミットのほぼ中間にある1つのコミットオブジェクトに出力を制限します。(存在する場合)bad bisection ref refs/bisect/bad が含まれるコミットに追加され、（存在する場合)good bisection ref refs/bisect/good-* が除外されるコミットに追加されることに注意してください。したがって、 refs/bisect/ にrefsがないと仮定すると、 

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

は、2つのコマンドの出力である中間点(midpoint)を出力します

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

上記は、ほぼ同じ長さになります。 したがって、回帰を導入する変更を見つけることは、バイナリ検索(binary search)に還元されます。コミットチェーンの長さが1になるまで、新しい中間点(midpoint)を繰り返し生成してテストします。

--bisect-vars

これは、 refs/bisect/ 内のrefが使用されないこと、およびシェルによって評価される準備ができているテキストを出力することを除いて、 --bisect と同じように計算されます。これらの行は、中間点リビジョンの名前を変数 bisect_rev に割り当て、 bisect_rev が bisect_nr にテストされた後にテストされるコミットの予想数、 bisect_rev が bisect_good`に適していることが判明した場合にテストされるコミットの予想数、 `bisect_rev が bisect_bad に不適切であることが判明した場合にテストされるコミットの予想数、および現在 bisect_all に二等分しているコミットの数です。

--bisect-all

これにより、含まれるコミットと除外されるコミットの間のすべてのコミットオブジェクトが、含まれるコミットと除外されるコミットまでの距離順に出力されます。 refs/bisect/ のrefは使用されません。それらから最も遠いものが最初に表示されます。(これは --bisect によって表示される唯一のものです。)

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

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

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リポジトリのパッキングを対象としています。

--objects

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

--in-commit-order

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

--objects-edge

--objects に似ていますが、接頭辞 “-” 文字が付いた除外されたコミットのIDも出力します。これは git-pack-objects(1) によって使用され、ネットワークトラフィックを削減するために、これらの除外されたコミットに含まれるオブジェクトに基づいてオブジェクトを削除された形式で記録する「薄い」パック(thin pack)を構築します。

--objects-edge-aggressive

--objects-edge に似ていますが、時間がかかるという犠牲を払って、除外されたコミットを見つけためにもっともっと頑張ります。これは、--objects-edge の代わりに使用されて浅いリポジトリ(shallow repositories)用の「薄い」パック(thin pack)を構築します。

--indexed-objects

インデックスで使用されるすべてのツリーとブロブがコマンドラインにリストされているかのように見せかけます。 注意: たぶんあなたは一緒に --objects も使用したいと思うでしょう。

--unpacked

--objects と一緒の時のみ役立ちます。パックに含まれていないオブジェクトIDを出力します。

--object-names

--objects でのみ有用です。 見つかった オブジェクトID の名前を出力します。 これはデフォルトの振る舞いです。 各オブジェクトの「名前」は曖昧であり、 主にオブジェクトをパッキングするためのヒントとして意図されていることに注意してください。 特に、タグとツリーとブロブの名前は区別されません。 パス名を変更して改行を削除することもできます。 また、 オブジェクトが異なる名前で複数回あらわれる場合は、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 単位のサイズのブロブが省略されます。 nはゼロの場合があります。 接尾辞kとmとgを使用して、 KiBまたはMiBまたはGiBの単位にすることができます。 たとえば、 blob:limit=1k は blob:limit=1024 と同じです。

--filter=object:type=(tag|commit|tree|blob) の形式では、要求されたタイプではないすべてのオブジェクトが省略されます。

--filter=sparse:oid=<blob-ish> の形式は、ブロブ(またはブロブ式) <blob-ish> に含まれるsparse-checkout仕様を使用して、 要求されたrefsでsparse checkoutに必要のないブロブを省略します。

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

注意: ファイルシステム上の任意のパスから読み取れる形式である --filter=sparse:path=<path> は、セキュリティ上の理由から削除されたことに注意してください。

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

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

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

--no-filter

以前の --filter= 引数をすべてオフにします。

--filter-provided-objects

明示的に提供されたオブジェクトのリストをフィルタリングします。そうしないと、どのフィルターとも一致しなくても常に出力されます。 --filter= と一緒に使った時のみ役に立ちます。

--filter-print-omitted

--filter= と一緒の時のみ役立ちます。フィルタによって省略されたオブジェクトのリストを出力します。オブジェクトIDの前には “~” 文字が付いています。

--missing=<missing-action>

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

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

--missing=allow-any の形式を使用すると、欠落しているオブジェクトが検出された場合でも、オブジェクトの走査を続行できます。欠落しているオブジェクトは、結果から黙って省略されます。

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

--missing=print の形式は allow-any に似ていますが、欠落しているオブジェクトのリストも出力します。オブジェクトIDの前には “?” 文字が付いています。

トラバーサルへ渡された先端(tip)が見つからない場合、 それらも欠落しているとみなされ、 トラバーサルはそれらを無視します。 ただし、 それらのオブジェクト ID を取得できない場合は、 エラーが発生します。

--exclude-promisor-objects

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

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

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

--do-walk

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

Commit Formatting

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

--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)。

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

--header

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

--no-commit-header

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

--commit-header

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

--parents

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

--children

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

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

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

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

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

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

--count

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

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)(行折り曲げされてない件名と本文)

      %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

EXAMPLES

  • 現在のブランチから到達可能なコミットのリストを出力します。 

    git rev-list HEAD

  • このブランチのコミットのリストを出力しますが、上流ブランチのは表示しません。 

    git rev-list @{upstream}..HEAD

  • 作者(author)とコミットメッセージを使用してコミットをフォーマットします(磁器コマンドのgit-log(1)も参照)。 

    git rev-list --format=medium HEAD

  • コミットとその差分をフォーマットします(これを単一のプロセスで実行できる磁器コマンドのgit-log(1)も参照してください)。 

    git rev-list HEAD |
git diff-tree --stdin --format=medium -p

  • 現在のブランチで、`Documentation`ディレクトリ内のファイルに関連(touch)したコミットのリストを出力します。 

    git rev-list HEAD -- Documentation/

  • 任意のブランチ・タグ・他のrefから過去1年間に作者you@example.comが作成したコミットのリストを出力します。 

    git rev-list --author=you@example.com --since=1.year.ago --all

  • 現在のブランチから到達可能なオブジェクトのリストを出力します(つまり、すべてのコミットと、それらに含まれるブロブとツリー)。 

    git rev-list --objects HEAD

  • 到達可能なすべてのオブジェクトのディスクサイズ、reflogから到達可能なオブジェクト、およびパックされた合計サイズを比較します。これにより、`git repack -ad`を実行すると(到達不能なオブジェクトを削除することで)リポジトリのサイズが減少するかどうか、およびreflogの有効期限が切れる(expire)ことによってリポジトリのサイズ減少に役立つかどうかがわかります。 

    # reachable objects
git rev-list --disk-usage --objects --all
# plus reflogs
git rev-list --disk-usage --objects --all --reflog
# total disk size used
du -c .git/objects/pack/*.pack .git/objects/??/*
# alternative to du: add up "size" and "size-pack" fields
git count-objects -v

  • 現在のブランチで使用されているオブジェクトを除いて、各ブランチのディスクサイズを報告します。 これにより、リポジトリサイズの肥大化の原因となっているイレギュラー値を見つけることができます(たとえば、誰かが誤って大きなビルドアーティファクトをコミットしたためとか)。 

    git for-each-ref --format='%(refname)' |
while read branch
do
        size=$(git rev-list --disk-usage --objects HEAD..$branch)
        echo "$size $branch"
done |
sort -n

  • (別のグループを除いた)refsの単一のグループのブランチのディスク上のサイズを比較します。1つのリポジトリに複数のリモートからのオブジェクトを混在させる場合、これにより、リポジトリ内で、どのリモートがどれだけ占めているかを示すことができます(`origin`のサイズを基準値として使用)。 

    git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin

GIT

Part of the git(1) suite