日本語 ▾ トピック ▾ 最新バージョン ▾ git-replay は 2.50.0 で最終更新

名前

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

概要

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

説明

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

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

オプション

--onto <newbase>

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

--onto を指定すると、出力の update-ref コマンドは、改訂範囲内のブランチを新しいコミットを指すように更新します。これは git rebase --update-refs が影響を受ける範囲内の複数のブランチを更新する方法に似ています。

--advance <branch>

新しいコミットを作成する開始点。ブランチ名である必要があります。

--advance を指定すると、出力の update-ref コマンドは、--advance の引数として渡されたブランチを新しいコミットを指すように更新します (つまり、これは cherry-pick 操作を模倣します)。

<revision-range>

リプレイするコミットの範囲。複数の <revision-range> を渡すことができますが、--advance <branch> モードでは、<branch> がどこを指すべきかが明確になるように、単一の先端を持つ必要があります。git-rev-parse[1] の「範囲の指定」と以下の「コミットの制限」オプションを参照してください。

コミットの制限

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

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

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

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

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

--skip=<number>

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

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

特定の時刻よりも新しいコミットを表示します。

--since-as-filter=<date>

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

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

特定の時刻よりも古いコミットを表示します。

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

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

--grep-reflog=<pattern>

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

--grep=<pattern>

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

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

--all-match

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

--invert-grep

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

-i
--regexp-ignore-case

大文字と小文字を区別せずに正規表現制限パターンに一致させます。

--basic-regexp

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

-E
--extended-regexp

制限パターンを、デフォルトの基本正規表現ではなく拡張正規表現とみなします。

-F
--fixed-strings

制限パターンを固定文字列とみなします (パターンを正規表現として解釈しません)。

-P
--perl-regexp

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

これらのタイプの正規表現のサポートは、オプションのコンパイル時依存関係です。Git がそれらのサポートなしでコンパイルされた場合、このオプションを指定すると終了します。

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

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

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

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

--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つのブランチ AB がある場合、それらの片側にのみ存在するすべてのコミットをリストする一般的な方法は --left-right を使用することです (--left-right オプションの説明の以下の例を参照)。ただし、これは他のブランチから cherry-pick されたコミットを示します (たとえば、「3rd on b」はブランチ A から cherry-pick された可能性があります)。このオプションを使用すると、このようなコミットのペアは出力から除外されます。

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

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

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

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

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

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

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

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

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

--merge

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

--boundary

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

履歴の簡素化

履歴の一部、例えば特定の <path> を変更するコミットにのみ興味がある場合があります。しかし、履歴の簡素化には2つの部分があり、1つはコミットの選択、もう1つはそれをどのように行うかであり、履歴を簡素化するための様々な戦略があります。

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

<paths>

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

--simplify-by-decoration

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

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

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

デフォルトモード

ツリーの最終状態を説明する最も単純な履歴に履歴を簡素化します。最も単純とは、最終結果が同じである場合 (つまり、同じ内容のブランチをマージする場合) に一部のサイドブランチをプルーニングするためです。

--show-pulls

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

--full-history

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

--dense

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

--sparse

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

--simplify-merges

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

--ancestry-path[=<commit>]

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

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

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

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

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

履歴 A---Q の水平線は、各マージの最初の親であると見なされます。コミットは

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

  • A では、foo は「foo」のみを含みます。

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

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

  • Dfoo を「baz」に設定します。そのマージ O は、ND の文字列を組み合わせて「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 が削除されました。なぜなら、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 の祖先であるコミットを除外します。これは、「M には D に存在しなかった何があるのか」という意味で、D 以降の M に至る履歴で何が起こったかを確認するのに役立ちます。この例の結果は、AB (そしてもちろん D 自体) を除くすべてのコミットになります。

しかし、D によって導入されたバグによって汚染され、修正が必要な M 内のコミットを見つけたい場合、実際に D の子孫である D..M のサブセットのみを表示したい場合があります。つまり、CK を除外します。これがまさに --ancestry-path オプションが行うことです。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 は、重要なブランチにマージするために使用されたマージコミットである可能性は低いです。代わりに、マージ N は、RX を重要なブランチにマージするために使用されました。このコミットには、変更 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 としてマークされます (簡素化の対象となります)。

コミットの順序付け

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

--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>]
--format=<format>

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

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

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

--abbrev-commit

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

これにより、「--pretty=oneline」が80桁の端末を使用する人々にとって格段に読みやすくなるはずです。

--no-abbrev-commit

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

--oneline

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

--encoding=<encoding>

コミットオブジェクトは、ログメッセージに使用された文字エンコーディングをエンコーディングヘッダーに記録します。このオプションを使用すると、コマンドに、ユーザーが好むエンコーディングでコミットログメッセージを再エンコードするように指示できます。非配管コマンドの場合、これはデフォルトで 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) ではタブが展開されます。

--notes[=<ref>]

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

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

オプションの <ref> 引数を使用すると、表示するノートを見つけるために参照を使用します。参照が 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[=<ref>]
--[no-]standard-notes

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

--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:... は、%s、%z、%Z を除く形式 ... をシステム strftime に渡します。これらは内部で処理されます。--date=format:%c を使用して、システムロケールの優先形式で日付を表示します。書式指定子の完全なリストについては、strftime マニュアルを参照してください。-local を使用する場合の正しい構文は --date=format-local:... です。

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

--parents

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

--children

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

--left-right

対称差分のどちら側からコミットが到達可能であるかを示します。左側のコミットには < が、右側のコミットには > がプレフィックスとして付きます。--boundary と組み合わせると、それらのコミットには - がプレフィックスとして付きます。

たとえば、次のようなトポロジの場合、

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

次のような出力が得られます。

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

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

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

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

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

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

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

出力

競合がない場合、このコマンドの出力は 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 以外になります。

mybranchtarget にリベースするだけの場合

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

mybranch から target へコミットをチェリーピックする場合

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

これは、branch1branch2branch3 のすべてを同時にリベースし、base 以降のコミットをすべて origin/main の上に再生します。これらの3つのブランチは、base の上に共通のコミットを持つことができますが、そうである必要はありません。

GIT

git[1]スイートの一部

scroll-to-top