意外導致的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

回答

相關問題