git-range-diff - 2つのコミット範囲（例：ブランチの2つのバージョン）を比較します。

このコマンドは、パッチシリーズの2つのバージョン、またはより一般的には2つのコミット範囲（マージコミットは無視）の違いを示します。

<path>引数が存在する場合、これらのコミット範囲はそれに応じて制限されます。

そのため、まず、互いに対応する両方のコミット範囲からコミットのペアを見つけます。2つのコミットは、それらのパッチ（つまり、作者情報、コミットメッセージ、およびコミットの差分）の違いが、パッチのサイズに比べて合理的に小さい場合、対応しているとみなされます。「アルゴリズム」セクションで詳細を参照してください。

最後に、一致するコミットのリストが2番目のコミット範囲の順序で表示され、一致しないコミットは、すべての祖先が表示された直後に挿入されます。

コミット範囲を指定する方法は3つあります。

git range-diffは、通常のdiffオプション（git-diff[1]を参照）も受け入れます。特に、--color=[<when>]と--no-colorオプションがあります。これらのオプションは、「パッチ間の差分」を生成する場合、つまり対応する古い/新しいコミットの作者、コミットメッセージ、および差分を比較する場合に使用されます。これらのパッチを生成する際にgit logに渡されるdiffオプションの大部分を調整する手段は現在ありません。

range-diffコマンドの出力は変更される可能性があります。これは、人間が読みやすいポーセリン出力として意図されており、Gitのバージョン間でテキスト的に安定したrange-diffを取得するために使用できるものではありません（git-patch-id[1]の--stableオプションとは対照的です）。range-diffに対するgit-apply[1]に相当するものもありません。出力は機械可読であることを意図していません。

これは、diffオプションを渡す場合に特に当てはまります。現在、--statのような一部のオプションは、出現効果として、range-diffのコンテキストでは非常に役に立たない出力を生成する可能性があります。将来のバージョンのrange-diffは、range-diffに固有の方法でこのようなオプションを解釈するようになる可能性があります（例：--statの場合、差分統計がどのように変化したかを要約した人間が読みやすい出力を生成します）。

このコマンドは、diff.color.*とpager.range-diffの設定を使用します（後者はデフォルトで有効になっています）。git-config[1]を参照してください。

rebaseでマージ競合の解決が必要になった場合、rebaseによって導入された変更を直後に比較するには、以下を使用します。

git range-diffの典型的な出力は次のようになります。

この例では、古いコミットが3つ、新しいコミットが3つあり、開発者は3番目のコミットを削除し、最初の2つのコミットの前に新しいコミットを追加し、2番目のコミットのコミットメッセージと差分を変更しました。

出力がターミナルに出力されると、デフォルトで通常のgit diffの出力と同様に、色分けされます。さらに、最初の行（コミットの追加）は緑色、最後の行（コミットの削除）は赤色、2行目（完全に一致）はgit showのコミットヘッダーのような黄色、3行目は古いコミットを赤色、新しいコミットを緑色、残りをgit showのコミットヘッダーのように色付けします。

しかし、実際には、差分のナイーブな色分けされた差分は、行全体を赤または緑で色付けするため、少し読みづらいです。例えば、古いコミットで「予期せぬこと」を追加した行は、古いコミットの意図が何かを追加することだったとしても、完全に赤色です。

それを解決するために、rangeはデフォルトで--dual-colorモードを使用します。このモードでは、差分の差分は元の差分の色を保持し、行の前に-/+マーカーを付け、その**背景**を赤または緑にして、差分自体がどのように変化したかをより明確にします。

一般的なアイデアは次のとおりです。両方のコミット範囲のコミット間にコスト行列を生成し、最小コスト割り当てを解決します。

コスト行列は次のように構成されます。コミットの各ペアに対して、両方の差分が生成され、「差分の差分」が3行のコンテキストと共に生成され、その差分の行数がコストとして使用されます。

誤検知（例えば、パッチが削除され、同じパッチシリーズの2回の反復の間に関連のないパッチが追加された場合など）を避けるため、一括削除/追加に対する固定コストエントリを追加することで、コスト行列を拡張します。

例：コミット1--2をパッチシリーズの最初の反復、A--Cを2回目の反復とします。Aが2のチェリーピックであり、Cが1のチェリーピックだが小さな修正（例えば、タイプミス修正）が含まれていると仮定します。コミットを二部グラフとして視覚化します。

古いシリーズに関して、新しいシリーズの「最適な」説明を探しています。この「説明」をグラフのエッジとして表現できます。

変更がないため、この説明は「無料」です。同様に、Cは1を使用して説明できますが、修正があるため、コストc>0がかかります。

数学的に言えば、最小コストの二部マッチングを探しています。1はコストをかけてCにマッチングされます。基礎となるグラフは実際には完全二部グラフです。各エッジに関連付けるコストは、2つのコミットのパッチ間の差分のサイズです。新しいコミットも説明するために、両側にダミーノードを導入します。

エッジo--Cのコストは、Cの差分のサイズで、100％未満であるべきファッジファクターで修正されます。エッジo--oのコストは無料です。ファッジファクターは、1とCに共通点がない場合でも、空行などがいくつか共有されている可能性があり、1とCに共通点がない場合でも、1--C、o--oの割り当てが1--o、o--Cよりもわずかに安価になる可能性があるため必要です。ファッジファクターを使用することで、パッチを対応するものと見なすために、はるかに大きな共通部分が必要です。

このアルゴリズムの計算に必要な全体的な時間は、n+m個のコミット差分とn*m個のパッチ差分の計算時間、そしてnとmの差分間の最小コスト割り当てを計算する時間です。Gitは、割り当て問題を解決するためにJonker-Volgenantアルゴリズムの実装を使用しており、時間計算量は三次です。この場合に見つかったマッチングは次のようになります。

git-log[1]

git[1]スイートの一部