4

（gitを使用して）作成しているdiffファイルにもう少し注意を払い始めましたが、この状況で作成されるdiffの明確さに不満があります。

私はから始めます：

sub main {
    my $self = shift;

    return $self;
}

次に、2番目の関数を追加し、最初の関数を呼び出して次の関数を取得します。

sub main {
    my $self = shift;

    $self -> process ( 'hello world!' );

    return $self;
}

sub process {
    my $self = shift;

    print @_, "\n";

    return $self;
}

そのために取得するdiff出力は次のとおりです。

@@ -1,5 +1,15 @@
 sub main {
    my $self = shift;

+   $self -> process ( 'hello world!' );
+   
+   return $self;
+}
+
+sub process {
+   my $self = shift;
+   
+   print @_, "\n";
+   
    return $self;
 }

これは私には非常に乱雑で不明瞭に思えます。追加のチャンクにより、実際にはほとんど行を追加した後、「main」関数に多くの行を追加しているように見えます。たとえば、diffが次のようになることを期待/希望します。

@@ -1,5 +1,15 @@
 sub main {
    my $self = shift;

+   $self -> process ( 'hello world!' );
+   
    return $self;
 }
+
+sub process {
+   my $self = shift;
+   
+   print @_, "\n";
+   
+   return $self;
+}

なぜdiffがこの出力を作成しているのか（「a-> b」からの最も簡単な方法）は理解していますが、もっと明確にできるかどうかを知りたいと思います。これは可能ですか？または、diffを手動で編集することを検討していますか、それとも新しい関数の追加とそれへの呼び出しを2つの別々のパッチ/コミットに分割することを検討していますか？[1]

--no-minimal、-patience、-histogramアルゴリズムを使用してみましたが、diffの結果は同じです。'git add -p'を使用してdiffを手動で編集しても違いはありませんが、それでも最初の「不明確な」diffとしてステージングされます。

[1]副次的な質問として、この分離は、とにかくコミット的に行うことになっていることですか？

4

2 に答える 2

1

通常、人々はそのような変更を複数のコミットに分けません。一般に、各コミットを独立させようとするのがルールです。それを複数のコミットに分割したとしても、多くの場合、人々はそれらのいずれかのコミット前の状態と両方のコミット後の状態の差分を見ているため、表示されているのと同じタイプの出力が表示されます。

git add -p出力される差分に影響を与えるために絶対に使用しても機能しません。これは、どの変更が次のコミットに適用されるかをより詳細に制御する方法にすぎません。いずれにせよ、コミットは作業中のツリーの新しいコンテンツのみで構成され、以前のバージョンとの差分は記録されません。後で表示される差分は、リクエストされるたびに計算されます。

これを回避するのに役立つことの 1 つは# End of <function name>、各関数の右中括弧の後に次のようなコメントを入れることです。しかし、それにはそれ自身の醜さがあります。実際のコードでは、さまざまな関数間の共通性が低くなる可能性が高いため、誤解を招く可能性が低くなります。しかし、いずれにせよ、ほとんどの人が慣れているものです。

于 2012-12-02T04:39:58.193 に答える
0

git diff man pageによると、diff のデフォルトのコンテキストは 3 行です。(可能性のある) 独立した変更の 2 つのハンクが近くにあり、したがってオーバーラップする場合、それらは1 つの共通のハンクに結合されます。

あなたはそれと一緒に暮らすか、常に-U<n>オプションを使用することができます

<n>通常の 3 行ではなく、コンテキストの行で差分を生成します

あなたの差分で

于 2012-12-02T05:42:27.293 に答える