日本語 ▾ トピック ▾ 最新バージョン ▾ git-rev-list は2.50.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 bisectgit 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>

出力するコミットを、指定されたパターン(正規表現)に一致する参照ログエントリを持つものに制限します。複数の --grep-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

親が複数あるコミットを出力しません。これは --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 はすべてのオクトパスマージを示します。

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

--first-parent

含めるコミットを検索する際、マージコミットを見たときに最初の親コミットのみをたどります。このオプションは特定のトピックブランチの進化を閲覧する際により良い概要を提供することができます。なぜなら、トピックブランチへのマージは時折、更新されたアップストリームへの調整のみを目的としている傾向があり、このオプションはそのようなマージによって履歴に取り込まれた個々のコミットを無視することを可能にするからです。

--exclude-first-parent-only

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

--not

これ以降のすべてのリビジョン指定子に対して、^ プレフィックス (またはその欠如) の意味を、次の --not まで反転させます。コマンドラインで --stdin の前に使用された場合、stdin を通じて渡されるリビジョンには影響しません。逆に、標準入力経由で渡された場合、コマンドラインで渡されるリビジョンには影響しません。

--all

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

--branches[=<pattern>]

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

--tags[=<pattern>]

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

--remotes[=<pattern>]

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

--glob=<glob-pattern>

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

--exclude=<glob-pattern>

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

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

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

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

--reflog

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

--alternate-refs

代替リポジトリの参照ヒントとして言及されているすべてのオブジェクトがコマンドラインにリストされているかのように扱います。代替リポジトリとは、オブジェクトディレクトリが 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

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

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

--left-only
--right-only

左右対称差分のそれぞれの側にあるコミットのみをリストアップします。つまり、--left-right によってそれぞれ < または > とマークされるもののみです。

たとえば、--cherry-pick --right-only A...B は、B のコミットのうち、A に含まれるか、A のコミットとパッチ的に同等なものを省略します。言い換えれば、これは 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

コミット履歴チェーンをたどる代わりに、最新のエントリから古いエントリへと参照ログエントリをたどります。このオプションを使用する場合、除外するコミットを指定することはできません(つまり、^commitcommit1..commit2、および commit1...commit2 の表記は使用できません)。

oneline および reference 以外の --pretty フォーマット (明らかな理由により) では、出力に参照ログから取得した2行の追加情報が含まれます。出力の参照ログ指定子は、いくつかのルールに応じて、ref@{<Nth>} (<Nth> は参照ログの逆時系列インデックス) または 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_HEADCHERRY_PICK_HEADREVERT_HEAD、または REBASE_HEAD のうち、最初に存在する擬似参照です。インデックスに未マージのエントリがある場合にのみ機能します。このオプションは、3ウェイマージからの競合を解決する際に、関連するコミットを表示するために使用できます。

--boundary

除外された境界コミットを出力します。境界コミットには - がプレフィックスされます。

--use-bitmap-index

(利用可能な場合)パックビットマップインデックスを使用して走査を高速化しようとします。--objects を使用して走査する場合、ツリーとブロブには関連するパスは出力されません。

--progress=<header>

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

-z

各出力オブジェクトとその付随メタデータは、改行区切りではなく、NULバイトで区切られます。出力は以下の形式で表示されます。

<OID> NUL [<token>=<value> NUL]...

オブジェクトパスや境界オブジェクトなどの追加のオブジェクトメタデータは、<token>=<value> の形式で出力されます。トークン値は、エンコード/切り捨てなしでそのまま出力されます。OIDエントリには = 文字は含まれず、新しいオブジェクトレコードの開始を通知するために使用されます。例:

<OID> NUL
<OID> NUL path=<path> NUL
<OID> NUL boundary=yes NUL
<OID> NUL missing=yes NUL [<token>=<value> NUL]...

このモードは、--objects--boundary、および --missing の出力オプションとのみ互換性があります。

履歴の簡素化

履歴の一部にのみ関心がある場合があります。例えば、特定の <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> 自身である範囲内のコミットのみを表示します。コミットが指定されていない場合、commit1 (範囲の除外部分) を <commit> として使用します。複数回渡すことができます。その場合、指定されたコミットのいずれかであるか、それらのいずれかの祖先または子孫である場合にコミットが含まれます。

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

fooを<paths>として指定したと仮定します。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」のみを含みます。

  • 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 と比較して、NP、および Q の主要な違いに注目してください。

  • 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 オプションが exactly に行うことです。D..M の範囲に適用すると、次のようになります。

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

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

代わりに、この範囲内の特定のトピックと、そのトピックに影響を受けるすべてのコミットに興味がある場合、D..M のサブセットのうち、そのトピックが履歴パスに含まれるもののみを表示したい場合があります。例えば、--ancestry-path=H D..M を使用すると、次のようになります。

		E
		 \
	      C---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--'

この例では、Ifile.txt を作成し、それが ABX によって異なる方法で変更されたと仮定します。単一親コミット CZYfile.txt を変更しません。マージコミット M は、AB の両方の変更を含むようにマージ競合を解決して作成されたため、いずれに対しても TREESAME ではありません。しかし、マージコミット R は、Mfile.txt の内容を無視し、Xfile.txt の内容のみを取ることによって作成されました。したがって、RX とは TREESAME ですが、M とは TREESAME ではありません。最後に、N を作成するための自然なマージ解決は、Rfile.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番目の問題は監査です。多くの貢献者が同じリポジトリで作業している場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。上記の問題のあるマージ R は、重要なブランチにマージするために使用されたマージコミットである可能性は低いです。代わりに、マージ NRX を重要なブランチにマージするために使用されました。このコミットには、変更 XAB からの変更を上書きするようになった理由に関する情報がコミットメッセージに含まれている可能性があります。

--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になるまで、新しい「中間点」を繰り返し生成してテストします。

--bisect-vars

これは --bisect と同じように計算しますが、refs/bisect/ 内の参照は使用されず、シェルで eval される準備ができたテキストを出力します。これらの行は、中間リビジョンの名前を変数 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---

ここで数字はコミットのタイムスタンプ順を表し、git rev-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

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

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

これらのオプションは主に 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] が「薄い」パックを構築するために使用します。これは、ネットワークトラフィックを削減するために、これらの除外されたコミットに含まれるオブジェクトに基づいてデルタ形式でオブジェクトを記録します。

--objects-edge-aggressive

--objects-edge と同様ですが、時間の増加を犠牲にして、除外されたコミットを見つけるためにより努力します。これは、浅いリポジトリ用の「薄い」パックを構築するために --objects-edge の代わりに使用されます。

--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=1kblob:limit=1024 と同じです。

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

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

形式 --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 エンコードされます)。+ および % 文字に加えて、以下の文字は予約されており、エンコードする必要があります: ~!@#$^&*()[]{}\;",<>?'` 、および 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-promisorallow-any と似ていますが、期待されるプロミサーの欠落オブジェクトに対してのみオブジェクトの走査を続行させます。予期しない欠落オブジェクトはエラーを発生させます。

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

形式 --missing=print-infoprint と似ていますが、そのコンテナオブジェクトから推測される欠落オブジェクトに関する追加情報も出力します。情報はすべて、欠落オブジェクトIDとともに ?<oid> [<token>=<value>]... の形式で同じ行に出力されます。<token>=<value> のペアは、SP で区切られて追加情報を含んでいます。値はトークン固有の方法でエンコードされますが、値に含まれる SP または LF は、結果としてエンコードされた値にこれらの問題のあるバイトのいずれも含まれないように表現されることが常に期待されます。各 <token>=<value> は以下のいずれかです。

  • path=<path> は、コンテナオブジェクトから推測される欠落オブジェクトのパスを示します。SP や特殊文字を含むパスは、必要に応じて C スタイルで二重引用符で囲まれます。

  • type=<type> は、格納しているオブジェクトから推測される、欠落しているオブジェクトの型を示します。

走査に渡されたヒントの一部が欠落している場合、それらも欠落していると見なされ、走査はそれらを無視します。ただし、オブジェクト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進数コミットオブジェクト名を表示します。これは --abbrev-commit を打ち消します。これは明示的または "--oneline" のような他のオプションによって暗黙的に設定されたものでも同様です。また、log.abbrevCommit 変数も上書きします。

--oneline

これは、「--pretty=oneline --abbrev-commit」を一緒に使用するショートハンドです。

--encoding=<encoding>

コミットオブジェクトは、ログメッセージに使用された文字エンコーディングをヘッダーに記録しています。このオプションは、コマンドにコミットログメッセージをユーザーが好むエンコーディングに再コード化するように指示するために使用できます。配管コマンド以外では、これは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 設定変数は、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 オプションはエポックからの秒数(常にUTCで測定される)には影響しませんが、付随するタイムゾーンの値を切り替えます。

--date=human は、タイムゾーンが現在のタイムゾーンと一致しない場合にタイムゾーンを表示し、一致する場合は全体の日付を出力しません (つまり、「今年」の日付は年を出力せず、過去数日以内の日付は曜日だけを表示します)。古い日付の場合は時間と分も省略されます。

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

--date=format:... は、フォーマット ... をシステムの strftime に渡します。ただし、%s、%z、%Z は内部で処理されます。--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

コミットの内容を生の形式で出力します。各レコードは 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>が指定されている場合、それはデフォルトの文字列の代わりに表示される文字列です。

--count

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

きれいなフォーマット

コミットがマージであり、かつ整形フォーマットが 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=short が明示的に指定されていない限り、日付は --date=short でフォーマットされます。フォーマットプレースホルダを持つ他の format: と同様に、その出力は --decorate--walk-reflogs のような他のオプションの影響を受けません。

  • email

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

    email と同様ですが、コミットメッセージ内で "From " (0 個以上の ">" が先行) で始まる行は ">" で引用され、新しいコミットの開始と混同されないようにします。

  • raw

    raw フォーマットは、コミットオブジェクトに保存されている通りにコミット全体を表示します。特に、--abbrev または --no-abbrev が使用されているかどうかにかかわらず、ハッシュは完全に表示され、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.<<

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

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

      %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>: 指定された glob(7) パターンに一致するタグのみを考慮し、"refs/tags/" プレフィックスは除外します。

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

    %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 オプションで記述されているルールに従います。@ の前の部分は、コマンドラインで指定された refname です (したがって git log -g refs/heads/masterrefs/heads/master@{0} を生成します)。

    %gd

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

    %gn

    リフロッグ識別名

    %gN

    リフロッグ識別名 (.mailmap を尊重。 git-shortlog[1] または git-blame[1] を参照)

    %ge

    リフロッグ識別メール

    %gE

    リフロッグ識別メール (.mailmap を尊重。 git-shortlog[1] または git-blame[1] を参照)

    %gs

    リフロッグ件名

    %(trailers[:<options>])

    git-interpret-trailers[1] で解釈された本文のトレーラーを表示します。trailers 文字列の後にコロンとゼロ個以上のコンマ区切りオプションが続くことがあります。オプションが複数回指定された場合、最後の指定が優先されます。

    • 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>] を受け入れます。--type=bool git-config[1] で受け入れられる値 (例: yesoff) はすべて受け入れられます。=<value> なしでブールオプションを指定することは、=true を指定することと同等です。

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

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

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

  • tformat

    tformat: 形式は format: とまったく同じように機能しますが、"セパレータ" セマンティクスではなく "ターミネータ" セマンティクスを提供します。つまり、各コミットにはメッセージターミネータ文字 (通常は改行) が追加され、エントリ間にセパレータが配置されることはありません。これは、単一行形式の最後のエントリが、"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 rev-list HEAD
  • このブランチ上のコミットのうち、アップストリームブランチに存在しないもののリストを出力します。

    git rev-list @{upstream}..HEAD
  • コミットを作者とコミットメッセージでフォーマットします (磁器 git-log[1] も参照)。

    git rev-list --format=medium HEAD
  • コミットとその差分をフォーマットします (単一プロセスでこれを実行できる磁器 git-log[1] も参照)。

    git rev-list HEAD |
    git diff-tree --stdin --format=medium -p
  • Documentation ディレクトリ内のいずれかのファイルに触れた、現在のブランチ上のコミットのリストを出力します。

    git rev-list HEAD -- Documentation/
  • 過去1年間にあなたが作成した、任意のブランチ、タグ、またはその他の参照上のコミットのリストを出力します。

    git rev-list --author=you@example.com --since=1.year.ago --all
  • 現在のブランチから到達可能なオブジェクトのリストを出力します (つまり、すべてのコミットとそれらが含むブロブおよびツリー)。

    git rev-list --objects HEAD
  • 到達可能なすべてのオブジェクトのディスクサイズを、リフローグから到達可能なオブジェクトと、合計パックサイズと比較します。これにより、git repack -ad を実行するとリポジトリサイズが削減される可能性があるかどうか (到達不能なオブジェクトを削除することによって)、およびリフローグの期限切れが役立つかどうかを知ることができます。

    # 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
  • あるリフレッシュグループ内のブランチのオンディスクサイズを、別のグループを除外して比較します。複数のリモートからのオブジェクトを単一のリポジトリに混在させている場合、これにより、どのリモートがリポジトリサイズに貢献しているか (たとえば、origin のサイズをベースラインとして) を示すことができます。

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

GIT

git[1]スイートの一部

scroll-to-top