Git

git-replay は 2.49.0 で最終更新

名前

git-replay - 実験的: コミットを新しいベースにリプレイする、ベアリポジトリでも動作

概要

(EXPERIMENTAL!) git replay ([--contained] --onto <newbase> | --advance <branch>) <revision-range>…

説明

コミットの範囲を受け取り、それらを新しい場所へリプレイします。作業ツリーとインデックスは変更せず、参照も更新しません。このコマンドの出力は、関連するブランチを更新する git update-ref --stdin への入力として使用されることを意図しています (下記の「出力」セクションを参照)。

このコマンドは実験的です。動作が変更される可能性があります。

オプション

--onto <新しいベース>: 新しいコミットを作成する開始点。既存のブランチ名だけでなく、任意の有効なコミットを指定できます。

--onto が指定された場合、出力内の update-ref コマンドは、リビジョン範囲内のブランチを新しいコミットを指すように更新します。これは git rebase --update-refs が影響を受ける範囲内の複数のブランチを更新する方法と似ています。
--advance <ブランチ>: 新しいコミットを作成する開始点。ブランチ名である必要があります。

--advance が指定された場合、出力内の update-ref コマンドは、--advance の引数として渡されたブランチを新しいコミットを指すように更新します (言い換えれば、これは cherry-pick 操作を模倣します)。
<リビジョン範囲>: リプレイするコミットの範囲。複数の <リビジョン範囲> を渡すことができますが、--advance <ブランチ> モードでは、<ブランチ> がどこを指すべきかが明確になるように、単一の先端を持つ必要があります。詳細は git-rev-parse[1] の「範囲の指定」および下記の「コミットの制限」オプションを参照してください。

コミットの制限

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

特に明記されていない限り、より多くのオプションを使用すると、通常は出力がさらに制限されます (例: --since=<日付1> は <日付1> より新しいコミットに制限し、--grep=<パターン> と共に使用すると、ログメッセージに <パターン> と一致する行があるコミットにさらに制限します)。

これらは --reverse などのコミット順序付けおよび書式設定オプションの前に適用されることに注意してください。

-<数値>

-n <数値>

--max-count=<数値>

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

--skip=<数値>

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

--since=<日付>

--after=<日付>

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

--since-as-filter=<日付>

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

--until=<日付>

--before=<日付>

指定された日付よりも古いコミットを表示します。

--author=<パターン>

--committer=<パターン>

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

--grep-reflog=<パターン>

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

--grep=<パターン>

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

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

--all-match

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

--invert-grep

ログメッセージが --grep=<パターン> で指定されたパターンと一致しないコミットにのみ出力を制限します。

-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=<数値>

--max-parents=<数値>

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

除外するコミット (^ 付き) を検索する際、マージコミットを見たときに最初の親コミットのみをたどります。これは、任意の merges が有効なトピックブランチの変更である可能性があることを考慮して、リモートブランチから分岐した時点からのトピックブランチ内の変更セットを見つけるために使用できます。

--not

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

--all

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

--branches[=<パターン>]

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

--tags[=<パターン>]

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

--remotes[=<パターン>]

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

--glob=<glob-パターン>

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

--exclude=<glob-パターン>

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

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

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

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

--reflog

リファレンスログによって言及されているすべてのオブジェクトがコマンドラインで <コミット> としてリストされているかのように振る舞います。

--alternate-refs

代替リポジトリのリファレンス先端として言及されているすべてのオブジェクトがコマンドラインでリストされているかのように振る舞います。代替リポジトリとは、オブジェクトディレクトリが objects/info/alternates に指定されている任意のリポジリです。含まれるオブジェクトのセットは、core.alternateRefsCommand などによって変更されることがあります。git-config[1] を参照してください。

--single-worktree

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

--ignore-missing

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

--bisect

不正なバイセクト参照 refs/bisect/bad がリストされ、その後に --not および良好なバイセクト参照 refs/bisect/good-* がコマンドラインに続くかのように振る舞います。

--stdin

コマンドラインから引数を受け取るだけでなく、標準入力からも読み取ります。これはコミットと --all や --glob= のような擬似オプションを受け入れます。-- セパレータが見つかった場合、それに続く入力はパスとして扱われ、結果を制限するために使用されます。標準入力経由で読み取られる --not のようなフラグは、同じ方法で渡された引数にのみ適用され、その後のコマンドライン引数には影響しません。

--cherry-mark

--cherry-pick (下記参照) と同様ですが、同等のコミットを省略するのではなく = でマークし、異なるコミットを + でマークします。

--cherry-pick

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

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

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

コミットの祖先チェーンを辿る代わりに、最新のものから古いものへとリファレンスログエントリを辿ります。このオプションを使用する場合、除外するコミットを指定することはできません (つまり、^commit、commit1..commit2、および commit1...commit2 の表記は使用できません)。

oneline および reference 以外の --pretty フォーマット (明らかな理由により) では、出力にリファレンスログから取得された2行の追加情報が含まれます。出力のリファレンスログ指定子は、いくつかのルールに応じて ref@{<Nth>} (ここで <Nth> はリファレンスログの逆年代順インデックス) または ref@{<タイムスタンプ>} (そのエントリの <タイムスタンプ> 付き) として表示される場合があります。

開始点が ref@{<Nth>} として指定されている場合、インデックス形式で表示します。
開始点が ref@{now} として指定されていた場合、タイムスタンプ形式で表示します。
どちらも使用されていないが、コマンドラインで --date が指定された場合、--date で要求された形式でタイムスタンプを表示します。
それ以外の場合は、インデックス形式で表示します。

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

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

--merge

競合するパスに影響を与えるコミットを HEAD...<その他> の範囲で表示します。ここで <その他> は MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD または REBASE_HEAD の中で最初に存在する擬似参照です。インデックスに未マージのエントリがある場合にのみ機能します。このオプションは、3-way マージの競合を解決する際に、関連するコミットを表示するために使用できます。

--boundary

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

履歴の簡略化

履歴の一部、例えば特定の <パス> を変更するコミットにのみ関心がある場合があります。しかし、履歴の簡略化 には2つの側面があります。1つはコミットを選択すること、もう1つはそれをどのように行うかです。履歴を簡略化するための様々な戦略が存在するためです。

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

<パス>: 指定された <パス> を変更するコミットが選択されます。
--simplify-by-decoration: 特定のブランチまたはタグによって参照されるコミットが選択されます。

意味のある履歴を示すために、追加のコミットが表示される場合があることに注意してください。

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

デフォルトモード: ツリーの最終状態を説明する最も単純な履歴に簡略化します。最終結果が同じである場合 (つまり、同じ内容のブランチをマージする場合)、一部のサイドブランチを剪定するため、最も単純です。
--show-pulls: デフォルトモードからのすべてのコミットを含めますが、最初の親とは TREESAME ではないが、後の親とは TREESAME であるマージコミットもすべて含めます。このモードは、ブランチに「最初に導入された」変更のマージコミットを表示するのに役立ちます。
--full-history: デフォルトモードと同じですが、一部の履歴は剪定しません。
--dense: 選択されたコミットのみが表示されます。意味のある履歴にするために、いくつか追加で表示される場合があります。
--sparse: 簡略化された履歴内のすべてのコミットが表示されます。
--simplify-merges: --full-history の追加オプションで、このマージに貢献する選択されたコミットがないため、結果の履歴から不要なマージを削除します。
--ancestry-path[=<コミット>]: 表示するコミットの範囲 (例: commit1..commit2 または commit2 ^commit1) と、その範囲内のコミット <コミット> が与えられた場合、その範囲内で <コミット> の祖先、<コミット> の子孫、または <コミット> 自身であるコミットのみを表示します。コミットが指定されていない場合、commit1 (範囲の除外部分) を <コミット> として使用します。複数回渡すことができ、その場合、与えられたコミットのいずれかであるか、それらのいずれかの祖先または子孫である場合にコミットが含まれます。

さらに詳細な説明が続きます。

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」のみを含みます。
B は A と同じ変更を含みます。そのマージ M は自明であり、したがってすべての親に対して TREESAME です。
C は foo を変更しませんが、そのマージ N はそれを「foobar」に変更するため、どの親に対しても TREESAME ではありません。
D は foo を「baz」に設定します。そのマージ O は N と D の文字列を組み合わせて「foobarbaz」にします。つまり、どの親に対しても TREESAME ではありません。
E は quux を「xyzzy」に変更し、そのマージ P は文字列を組み合わせて「quux xyzzy」にします。P は O に対して TREESAME ですが、E に対しては TREESAME ではありません。
X は新しいファイル side を追加した独立したルートコミットで、Y がそれを変更しました。Y は X に対して TREESAME です。そのマージ Q は P に side を追加し、Q は P に対して TREESAME ですが、Y に対しては TREESAME ではありません。

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

デフォルトモード

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

これにより、次のような結果が得られます

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

TREESAME な親が存在する場合にのみその親をたどるというルールが、いかに B を考慮から完全に除外したかに注意してください。C は N を介して考慮されましたが、TREESAME です。ルートコミットは空のツリーと比較されるため、I は !TREESAME です。

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

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

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

	I  A  B  N  D  O  P  Q

M は両方の親に対して TREESAME であったため除外されました。E、C、B はすべてたどられましたが、B のみが !TREESAME であったため、他は表示されません。

親の書き換えなしでは、コミット間の親子関係について実際に語ることはできないため、それらを切断された状態で表示していることに注意してください。

--full-history (親の書き換えあり)

通常のコミットは、!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 である場合、その親のみをたどるため、マージの他の側面は決して走査されません。

--simplify-merges

まず、--full-history と親の書き換えが実行する方法 (上記参照) と同じ方法で履歴グラフを構築します。

次に、各コミット C を、以下のルールに従って最終履歴におけるその置き換え C' に簡略化します。

C' を C に設定します。
C' の各親 P をその簡略化された P' に置き換えます。この過程で、他の親の祖先である親、または空のツリーに対して TREESAME であるルートコミットを削除し、重複を削除しますが、TREESAME であるすべての親を削除しないように注意してください。
この親の書き換え後、C' がルートコミットまたはマージコミット (親がゼロまたは1より多い)、境界コミット、または !TREESAME である場合、それは残ります。それ以外の場合は、唯一の親に置き換えられます。

これの効果は、親の書き換えありの --full-history と比較することで最もよく示されます。例は次のようになります。

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

--full-history と比較して、N, P, Q の主な違いに注目してください。

N の親リストから I が削除されました。なぜなら、I は他の親 M の祖先であるためです。それでも、N は !TREESAME であるため残りました。
P の親リストも同様に I が削除されました。その後、P は親が1つで TREESAME であるため、完全に削除されました。
Q の親リストでは Y が X に簡略化されました。その後、X は TREESAME なルートであったため削除されました。その後、Q は親が1つで TREESAME であるため、完全に削除されました。

別の簡略化モードも利用可能です

--ancestry-path[=<コミット>]

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

使用例として、次のコミット履歴を考えてみましょう。

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

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

しかし、M 内で D によって導入されたバグに汚染され、修正が必要なコミットを見つけたい場合、D..M のうち実際に D の子孫であるサブセットのみ (つまり、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 は R に対して TREESAME ですが、C に対してはそうではありません。マージコミット O と P は、それぞれ最初の親に対しては TREESAME ですが、2番目の親である Z と Y に対してはそうではありません。

デフォルトモードを使用すると、N と R は両方とも TREESAME な親を持つため、これらのエッジが辿られ、他は無視されます。結果の履歴グラフは次のとおりです。

	I---X

--full-history を使用すると、Git はすべてのエッジを辿ります。これにより、コミット 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番目の親が最初の親から到達可能であるためです。それらのエッジは削除され、コミットは親に対して TREESAME である単一親コミットのように見えます。これはコミット N にも起こり、次のような履歴ビューになります。

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

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

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

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

--show-pulls

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

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

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

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

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

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

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

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

コミットの順序付け

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

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

--no-walk[=(sorted|unsorted)]: 指定されたコミットのみを表示し、その祖先は走査しません。範囲が指定されている場合、これは効果がありません。引数 unsorted が指定されている場合、コミットはコマンドラインで与えられた順序で表示されます。それ以外の場合 (sorted または引数が指定されていない場合)、コミットはコミット時間の逆年代順に表示されます。--graph と組み合わせることはできません。
--do-walk: 以前の --no-walk を上書きします。

コミットの書式設定

--pretty[=<形式>]

--format=<形式>

コミットログの内容を指定された形式で整形して出力します。ここで <形式> は、oneline, short, medium, full, fuller, reference, email, raw, format:<文字列> および tformat:<文字列> のいずれかです。<形式> が上記以外で、%プレースホルダー を含む場合、それは --pretty=tformat:<形式> が与えられたかのように動作します。

各形式に関する追加の詳細は、「PRETTY FORMATS」セクションを参照してください。=<形式> の部分が省略された場合、デフォルトは 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=<エンコーディング>

コミットオブジェクトは、ログメッセージに使用された文字エンコーディングをエンコーディングヘッダーに記録します。このオプションは、ユーザーが好むエンコーディングでコミットログメッセージを再エンコードするようにコマンドに指示するために使用できます。非プラミングコマンドの場合、これはデフォルトで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スペースでインデントする整形形式 (つまり、デフォルトである medium、full、および fuller) でタブが展開されます。

--notes[=<参照>]

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

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

オプションの <参照> 引数を指定すると、その参照を使用して表示するノートを見つけます。参照が refs/notes/ で始まる場合、完全な参照名を指定できます。notes/ で始まる場合、refs/ がプレフィックスとして付き、それ以外の場合は refs/notes/ がプレフィックスとして付いて完全な参照名が形成されます。

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

--no-notes

ノートを表示しません。これは、ノートが表示されるノート参照のリストをリセットすることで、上記の --notes オプションを無効にします。オプションはコマンドラインで与えられた順序で解析されるため、例えば「--notes --notes=foo --no-notes --notes=bar」は「refs/notes/bar」からのノートのみを表示します。

--show-notes-by-default

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

--show-notes[=<参照>]

--[no-]standard-notes

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

--show-signature

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

--relative-date

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

--date=<形式>

人間が判読できる形式で表示される日付にのみ効果があり、例えば --pretty を使用する場合などです。log.date 設定変数は、ログコマンドの --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:... は、%s、%z、%Z を除く形式 ... をシステム strftime に供給します。これらは内部で処理されます。システムロケールが好む形式で日付を表示するには、--date=format:%c を使用します。形式プレースホルダーの完全なリストについては、strftime マニュアルを参照してください。-local を使用する場合の正しい構文は --date=format-local:... です。

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

--parents

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

--children

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

--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[=<バリア>]

--graph が使用されていない場合、すべての履歴ブランチが平坦化され、2つの連続するコミットが直線的なブランチに属していないことが見えにくくなる場合があります。このオプションは、その場合にそれらの間にバリアを配置します。<バリア> が指定された場合、それはデフォルトの文字列の代わりに表示される文字列です。

出力

競合がない場合、このコマンドの出力は git update-ref --stdin の入力として使用できます。形式は次のとおりです。

update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}

ここで、更新される参照の数は、渡された引数とリプレイされる履歴の形状によって異なります。--advance を使用する場合、更新される参照の数は常に1つですが、--onto の場合は1つまたはそれ以上になる可能性があります (複数のブランチを同時にリベースすることがサポートされています)。

終了ステータス

競合のない正常なリプレイの場合、終了ステータスは0です。リプレイに競合がある場合、終了ステータスは1です。何らかのエラーによりリプレイが完了 (または開始) できない場合、終了ステータスは0または1以外の値になります。

例

mybranch を target にシンプルにリベースするには

$ git replay --onto target origin/main..mybranch
update refs/heads/mybranch ${NEW_mybranch_HASH} ${OLD_mybranch_HASH}

mybranch からのコミットを target に cherry-pick するには

$ git replay --advance target origin/main..mybranch
update refs/heads/target ${NEW_target_HASH} ${OLD_target_HASH}

最初の2つの例は、まったく同じコミットをまったく同じ新しいベースにリプレイすることに注意してください。違いは、最初の例が mybranch を新しいコミットを指すようにする指示を提供し、2番目の例が target をそれらを指すようにする指示を提供するだけです。

もし、互いに依存するブランチのスタックがあり、その全体をリベースしたい場合はどうでしょうか？

$ git replay --contained --onto origin/main origin/main..tipbranch
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/tipbranch ${NEW_tipbranch_HASH} ${OLD_tipbranch_HASH}

git replay を呼び出す際、A..B の構文を使用してリプレイするコミットの範囲を指定する必要はありません。任意の範囲表現で十分です。

$ git replay --onto origin/main ^base branch1 branch2 branch3
update refs/heads/branch1 ${NEW_branch1_HASH} ${OLD_branch1_HASH}
update refs/heads/branch2 ${NEW_branch2_HASH} ${OLD_branch2_HASH}
update refs/heads/branch3 ${NEW_branch3_HASH} ${OLD_branch3_HASH}

これにより、branch1、branch2、branch3 のすべてが同時にリベースされ、base 以降のすべてのコミットが origin/main の上に適用されます。これらの3つのブランチは、base の上に共通のコミットを持つ場合がありますが、必ずしもそうである必要はありません。

git[1] スイートの一部

セットアップと設定

プロジェクトの取得と作成

基本的なスナップショット作成

ブランチとマージ

プロジェクトの共有と更新

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

プラミングコマンド

名前

概要

説明