git-replay(1)

SYNOPSIS

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

DESCRIPTION

コミットの範囲を取得し、それらを新しい場所でリプレイします。作業ツリーとインデックスには触らず(untouch)、参照(references)は更新しません。このコマンドの出力は、関連するブランチを更新する git update-ref --stdin への入力として使用されることを目的としています(下記 OUTPUT セクションをご覧ください)

このコマンドは実験的なものです！振る舞いは変更される可能性があります！

OPTIONS

--onto <newbase>: Starting point at which to create the new commits. May be any valid commit, and not just an existing branch name.

--onto が指定されている場合、出力内の update-ref コマンドは、リビジョン範囲のブランチがその新しいコミットを指すように更新します。これは、 git rebase --update-refs が、影響を受ける範囲の複数のブランチを更新する方法と似ています。
--advance <branch>: Starting point at which to create the new commits; must be a branch name.

--advance が指定されている場合、出力内の update-ref コマンドは、新しいコミットを指すように --advance に引数として渡されたブランチを更新します(つまり、これは cherry-pick 操作を模倣します)。
<revision-range>: リプレイするコミットの範囲。複数の <revision-range> を渡すことができますが、「--advance <branch>」モードでは、<branch> がどこを指すのかが明確になるように、単一の先端(tip)であるべきです。 git-rev-parse(1) の「Specifying Ranges」と、下記の「Commit Limiting」オプションを参照してください。

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>

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

--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が当該のサポート付きでコンパイルされていない場合、このオプションを使うと、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

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

--bisect

コマンドラインで、bad bisection ref refs/bisect/bad がリストされ、その後に --not と good bisection ref refs/bisect/good-* が続くかのように見せかけます。

--stdin

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

--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> 付で)として表示されます。表示は下記のいくつかのルールに依存します:

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

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

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

History Simplification

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があります。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つはコミットの選択であり、もう1つはそれを行う方法です。

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

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

注意: 意味のある重要な履歴のために、追加のコミットを表示できることに注意してください。

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

Default mode: 履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最終結果が同じである場合(つまり、同じコンテンツのブランチをマージする場合)、いくつかの傍流ブランチ(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 を介して)親の書き換えが使用されているかどうかに基づいて、コミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下の設定が可能です。

Default mode

コミットは、どの親に対しても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としてマークされます(簡略化される可能性があります)。

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

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

Commit Formatting

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

--notes[=<ref>]

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

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

オプションの <ref> 引数を使用して、refを使用して表示するnotesを検索します。 refは、 refs/notes/ で始まる完全なrefnameを指定できます。 notes/ で始まるか、 refs/ で始まるか、それ以外で始まる場合、 refs/notes/ が接頭辞として付けられ、refのフルネームを形成します。

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

--no-notes

ノートを表示しないでください。これは、ノートが表示されるノート ref のリストをリセットすることにより、上記の --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 構成変数(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

--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)を置きます。 <barrier> が指定されている場合、デフォルトの障壁文字列の代わりに <barrier> が表示されます。

OUTPUT

競合がない場合、このコマンドの出力は 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}

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

EXIT STATUS

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

EXAMPLES

単純に「mybranch」を「target」上にリベースするには:

$ 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 つの例は、まったく同じ新しいベース上でまったく同じコミットをリプレイします。その 1 つ目例では mybranch が新しいコミットを指すようにする命令を提供し、その 2 つ目の例では target が新しいコミットを指すようにする命令が提供される点だけが異なります。

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

$ 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

Part of the git(1) suite

git-replay(1) Manual Page

NAME