意外的结果在git-diff中 [英] Unexpected result in 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; 
返回$ self-> send_error（ERROR_REQUEST_INVALID）
，除非已定义（$ 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）
  

code> my $ method = ref（$ message）eq'HASH'？ $ message-> {method}：undef; 根本没有改变：空白没有变化，EOL也是一样的

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

解决方案

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

在我们的特殊情况下，唯一允许的指令是删除符号和添加符号（不允许移动，但见下文）。此外，我们不知道每个符号的含义是什么，而每个符号是源代码行。

。

这两个符号是相同的，当且仅当它们完全匹配，或者（在打开某些行结束和/或空白选项的情况下）匹配后剥离一些项目（白色空间或回车，主要）。我们的工作是产生最小数量的删除和插入新命令。

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

git blame 允许 允许移动的不同算法。在允许移动时解决问题要困难得多，所以 git diff 就不用麻烦了。要在 git blame 中启用移动检测，请使用 -M 。

Why I get this patch:

@@ -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);

When remove empty line after 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)

I expect to see this patch instead of showed first one:

@@ -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)

The my $method = ref($message) eq 'HASH' ? $message->{method} : undef; did not changed at all: there is no change in whitespace and EOL is same

Maybe should I supply some extra options to git to get this behaviour?

解决方案

Git's diff implements a specific variant of the generalized minimal edit distance or string to string edit problem. We're given some initial set of symbols and some final set, and we are told to come up with the fewest edit instructions out of some limited set of edit commands.

In our particular case, the only allowed instructions are "delete symbol" and "add symbol" (there is no "move" allowed, but see below). Moreover, we have no knowledge of what each symbol means, but each "symbol" is a source line.

The two "symbols" are the same if and only if they match exactly, or (with certain end-of-line and/or white-space options turned on) match after stripping some items away (white space or carriage returns, mainly). Our job is to produce the smallest number of "delete" and "insert new" commands.

The diff you show has two "insert"s and one "delete". The diff Git produces also has two "insert"s and one "delete". As far as Git can tell, this makes them equal. The one it chooses is just a matter of which of several "equal" trace-back paths it chooses through a comparison matrix.

The code in git blame allows a different algorithm that does allow moves. Solving the problem when allowing moves is much harder, so git diff just doesn't bother. To enable move detection in git blame, use -M.

这篇关于意外的结果在git-diff中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！