意外导致的git-DIFF

为什么我得到这个补丁：意外导致的git-DIFF

@@ -129,8 +132,9 @@ sub _preprocess_message { 
sub _process_message { 
    my ($self, $message) = @_; 

- my $method = ref($message) eq 'HASH' ? $message->{method} : undef; 
+ my $time = [ gettimeofday ]; 

+ my $method = ref($message) eq 'HASH' ? $message->{method} : undef; 
    return $self->send_error(ERROR_REQUEST_INVALID) 
     unless defined($method);

当删除空行后my $method = ...：

@@ -129,6 +132,8 @@ sub _preprocess_message { 
sub _process_message { 
    my ($self, $message) = @_; 

+ my $time = [ gettimeofday ]; 
+ 
    my $method = ref($message) eq 'HASH' ? $message->{method} : undef; 

    return $self->send_error(ERROR_REQUEST_INVALID)

我希望看到这个补丁，而不是显示第一个：

@@ -129,6 +132,8 @@ sub _preprocess_message { 
sub _process_message { 
    my ($self, $message) = @_; 

+ my $time = [ gettimeofday ]; 
+ 
    my $method = ref($message) eq 'HASH' ? $message->{method} : undef; 
-  
    return $self->send_error(ERROR_REQUEST_INVALID)

my $method = ref($message) eq 'HASH' ? $message->{method} : undef;根本没有改变：空格没有变化，EOL是相同的

也许我应该为git提供一些额外的选项来获得这种行为？

来源

2016-11-11 Eugen Konkov

它真的很重要吗？最终结果是一样的，这就是差异如何对齐线条。 –

@MadPhysicist然而。它有问题。原线的作者改变了。后来有人应该采取额外的措施，而'git-blame'。但是这条线实际上并没有改变/移动 –

Git的差异实现广义最小编辑距离或串来串编辑问题的特定变化。我们给了一些最初的一组符号和一些最终设置，并且我们被告知从一些有限的编辑命令集中得到最少的编辑指令。

在我们的特殊情况下，唯一允许的指令是“删除符号”和“添加符号”（不允许“移动”，但见下文）。此外，我们不知道什么每个符号意味着知识，但每一个“符号”是源线。

两个“符号”是相同的，当且仅当它们完全匹配，或汽提一些物品离开（空格或运输后（与最终的线和/或空白某些选项接通）匹配主要返回）。我们的工作是产生最少数量的“删除”和“插入新的”命令。

您展示DIFF有两个“插入” S和一个“删除”。差异Git产生也有两个“插入”和一个“删除”。就Git而言，这使得他们平等。它选择的只是通过比较矩阵选择几个“相等”追溯路径中的哪一个。

在git blame该代码允许不同的算法，该算法确实允许移动。允许移动时解决问题要困难得多，所以git diff只是不打扰。要在git blame中启用移动检测，请使用-M。

来源

2016-11-11 16:24:09 torek

看来这将是非常有用的每个符号存储额外的元信息作为源线的长度。所以在这种情况下，当'git' counter两个相同的命令序列时，它会做进一步的比较：添加23个字符删除无VS添加75个字符删除46.我认为这不会像移动检测那么难，这个元信息将是有用的为其他事物/地方。 –

这实际上是一个打破关系的好主意。你应该尝试在Git中实现它，因为代码是广泛可用的。在当前版本中，它位于'xdiff/xdiffi.c'中。 – torek

git diff --patience产生你期望的结果。该方法尽量不要将行标记为未添加或删除。这不是默认的，因为它在计算上很昂贵。（当目的是生成稍后应用的补丁时，大多数时候diff是否看起来是这样或者那样并不重要）。

来源

2016-11-21 09:19:06 j6t

这有问题。原线的作者改变了。后来有人应该采取额外的措施，而'git-blame'。但该行实际上并没有改变/移动 –

@Eugen它看起来像'git blame --patience'被接受，但该标志被忽略:(。 – j6t

意外导致的git-DIFF

回答

相关问题