git - 統一された差分コンテキスト行の数を増やすと、マイナス面はありますか?

Question

デフォルトでは、コンテキスト行で統一された差分を生成しますdiff -u。git diffdiff ファイル自体のサイズとは別に、コンテキスト行の数を増やすことに何か不利な点はありますか? パッチが作成されてからパッチを適用するファイルが変更された場合に役立つと思います。具体的には、文脈行数を増やせばpatch失敗するケース、そうしなければならないケースはありますか？

Answer 1

はい。次のケースを検討してください。

ファイルがありますf1：

a
b
c
d
e
f
g

行を変更して、次のfいずれかを取得します

--- f1  2013-04-15 13:23:57.524966109 +0200
+++ f2  2013-04-15 13:25:17.832965720 +0200
@@ -5,3 +5,3 @@
 e
-f
+f2
 g

また

--- f1  2013-04-15 13:23:57.524966109 +0200
+++ f2  2013-04-15 13:25:17.832965720 +0200
@@ -1,7 +1,7 @@
 a
 b
 c
 d
 e
-f
+f2
 g

-U1または-U5オプションを とともに使用するかどうかによって異なりますdiff。他の誰かがファイルの上部セクションを次のように編集したとします。

a
b1
c
d
e
f
g

patch2 つのコマンドの出力は次のとおりです。

$ patch f3 < u1.patch 
patching file f3
$ patch f3 < u5.patch 
patching file f3
Hunk #1 succeeded at 1 with fuzz 2.

パッチは両方のシナリオで正常に適用されましたが、2 回目の実行では、ファズ値 2 を使用する必要がありました。これはどういう意味ですか?

最初のパッチは、コンテキストのすべての行が一致する場所を探します。そのような場所が見つからず、それがコンテキスト diff であり、最大ファズ係数が 1 以上に設定されている場合、コンテキストの最初と最後の行を無視して別のスキャンが行われます。それが失敗し、最大ファズ係数が 2 以上に設定されている場合、コンテキストの最初の 2 行と最後の 2 行は無視され、別のスキャンが行われます。

のこの説明からわかるように、このバージョンman patchで作成されたパッチは、この-U5ようなシナリオでは適用に時間がかかります。さらに悪いことに、で使用される fuzz 値patchが十分に大きくない場合、パッチの適用は失敗します。

Answer 2

コンテキストのサイズは、パッチに 2 つの大きな影響を与えます。

1. コンテキストが大きいほど、正しいコンテキストでパッチを適用していることを確信できます。
2. コンテキストが大きくなればなるほど、より多くの変更が 1 つのハンクにグループ化される可能性があります。

次の例を考えてみてください (スペルミスは意図的なものです)。

original file:                     Changed file:

This is                            This is
some tex.                          some text.
You are on                         You are on
stackoverflo.com                   stackoverflo.com
Completely unrelated               Completely unrelated
tet here.                          text here.
Goodbye.                           Goodbye.

コンテキスト サイズが 1 行の場合、2 つのハンクを含むパッチが得られます。

@@ -1,2 +1,3 @@
 This is
-some tex.
+some text.
 You are on
@@ -4,3 +5,3 @@
 Completely unrelated
-tet here.
+text here.
 Goodbye.

また、コンテキスト サイズが 3 行の場合、1 つのハンクを含むパッチが得られます。

@@ -1,6 +1,7 @@
 This is
-some tex.
+some text.
 You are on
 stackoverflo.com
 Completely unrelated
-tet here.
+text here.
 Goodbye.

次に、2 番目の修正を想像してください。

Changed file:                      Further changed file:

This is                            This is
some text.                         some text.
You are on                         You are on
stackoverflo.com                   stackoverflow.com
Completely unrelated               Completely unrelated
text here.                         text here.
Goodbye.                           Goodbye.

ここのパッチは次のとおりです。

@@ -3,3 +3,3 @@
 You are on
-stackoverflo.com
+stackoverflow.com
 Completely unrelated

ここで、パッチの順序を逆にするとします。したがって、最初に 2 番目のパッチ (flowアドレスの修正) を適用し、次に最初のパッチの 1 つ (-U 1またはを使用-U 3) を適用します。

• -U 1パッチがきれいに適用されている場合。
• -U 3パッチがクリーンではなく、パッチが失敗するか、ファズで受け入れられる場合があります。

結論

最初に両極端を考えてください。コンテキストがゼロの場合、パッチを間違えたり、ハンクを間違った行に適用したりすることは非常に簡単です。無限のコンテキストがある場合、すべてのパッチは基本的にファイル全体の置き換えになり、パッチの並べ替えが難しくなります。

したがって、コンテキストが低すぎても高すぎてもどちらも悪いということは容易に理解できます。したがって、マッチングの改善と個々の変更の発見との間には、明らかにトレードオフが必要です。

残念ながら、最適な行数はなく、デフォルトのコンテキスト サイズは、開発者の集合的な考えが公正なトレードオフとして受け入れるようになったものであると言えます。それがあなたの原因に役立つ場合は、それを増やすことができますが、その意味に注意してください.