4

我已经开始更加关注我正在创建的差异文件（使用 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;
 }

这对我的读者来说似乎很不整洁和不清楚。大量添加使我看起来像是在“主”函数中添加了很多行，而实际上我实际上在它之后添加了很多行。例如，我希望/喜欢差异是这样的：

@@ -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”开始的最简单方法），但希望它可以更清晰。这可能吗？或者我是否正在考虑手动编辑差异，甚至将新功能的添加和对它的调用分成 2 个单独的补丁/提交？[1]

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

[1] 作为一个附带问题，这种分离是我无论如何都应该做的事情吗？

4

2 回答 2

1

通常人们不会将这样的更改分成多个提交。通常，规则是尝试让每个提交独立。即使您确实将其拆分为多个提交，人们通常会查看其中任何一个提交之前的状态和它们之后的状态的差异，因此会看到您所看到的相同类型的输出。

使用git add -p绝对不会影响输出的差异。这只是一种更好地控制哪些更改进入下一次提交的方法。在任何情况下，提交仅包含您正在使用的树的新内容，它不会记录与先前版本的差异。每次请求时都会计算稍后显示的差异。

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

于 2012-12-02T04:39:58.193 回答
0

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

您可以忍受它或使用 always-U<n>选项

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

与您的差异

于 2012-12-02T05:42:27.293 回答