Question

我开始多关注我正在创建的差异文件（使用git），我对这种情况造成的差异的清晰度感到不满。

我从：

开始

sub main {
    my $self = shift;

    return $self;
}

然后我在第一个函数中添加第二个函数并调用它来获取：

sub main {
    my $self = shift;

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

    return $self;
}

sub process {
    my $self = shift;

    print @_, "\n";

    return $self;
}

我得到的差异输出是：

@@ -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'函数中添加了很多行，当我实际上大部分时间后添加了行。例如，我希望/喜欢差异就像这样：

@@ -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 - ＆gt; b”开始的最简单的方式），但是如果它可以变得更清楚的话。这可能吗？或者我是否正在手动编辑差异，甚至将新功能的添加和对它的调用分成2个单独的补丁/提交？ [1]

我尝试过使用--no-minimal，--patience和--histogram算法，但差异结果是相同的。使用'git add -p'手动编辑差异没有任何区别，它仍然是第一个“不清楚”的差异。

[1]作为一个附带问题，这种分离是我所谓的无论如何都要提交吗？

Answer 1

通常人们不会将这样的更改分成多个提交。通常，规则是尝试让每个提交都独立存在。即使你将它分成多个提交，通常人们会看到差异在这两个提交之前的状态和在它们之后的状态之前的状态，和所以看看你看到的输出类型相同。

使用git add -p肯定无法影响输出的差异。这只是一种更好地控制哪些变化进入下一个变化的方式承诺。在任何情况下，提交仅包含树的新内容你正在使用它，它不记录前一个差异版。稍后显示的差异将在每次计算时计算出来他们被要求了。

有助于避免这种情况的一件事是在每个函数的右括号之后添加# End of <function name>之类的注释。但这有它对它有自己的丑陋。在实际代码中，两者之间的共性可能较少不同的功能，因此差异的可能性较小误导。但无论如何，这是大多数人习惯的东西。

Answer 2

根据git diff man page，diff的默认上下文是3行。当两个（可能的）独立变化更接近并因此重叠时，它们会在一个共同的大块中结合

您可以使用它或始终使用-U<n>选项

使用<n>上下文行生成差异，而不是通常的三行

与你的差异

diff在现有的内部添加新功能而不是后添加

2 个答案: