git不顯示代碼被刪除的地方

所以我的任務是替換一些我們的項目爲了兼容性的原因需要的虛擬代碼，但自從上次發佈以來，它已經神祕地退出了某個時間。由於消失的代碼讓我擔心還有什麼可能已經失蹤，但未被發現，我一直在挖掘日誌，試圖找出這些少數行被刪除的內容。我已經嘗試了一些東西，包括「git log -S'add-visit-resource-pcf'」，git blame，甚至是用腳本對齊git bisect，這個腳本只是檢查行的存在，但一直無法精確定位確切地說，這些行被刪除。我發現這非常令人困惑，尤其是在我重新引入此代碼之前，最後一個日誌條目（通過上述命令獲得）之前還有其他人添加了代碼。git不顯示代碼被刪除的地方

commit 0b0556fa87ff80d0ffcc2b451cca1581289bbc3c 
Author: Andrew 
Date: Thu May 13 10:55:32 2010 -0400 

    Re-introduced add-visit-resource-pcf, see PR-65034. 

diff --git a/spike/hst/scheduler/defpackage.lisp b/spike/hst/scheduler/defpackage.lisp 
index f8e692d..a6f8d38 100644 
--- a/spike/hst/scheduler/defpackage.lisp 
+++ b/spike/hst/scheduler/defpackage.lisp 
@@ -115,6 +115,7 @@ 
    #:add-to-current-resource-pcf 
    #:add-user-package-nickname 
    #:add-value-criteria 
+ #:add-visit-resource-pcf 
    #:add-window-to-gs-params 
    #:adjust-derived-resources 
    #:adjust-links-candidate-criteria-types 

commit 9fb10e25572c537076284a248be1fbf757c1a6e1 
Author: Bob 
Date: Sun Jan 17 18:35:16 2010 -0500 

    update-defpackage for Spike 33.1 Delivery 

diff --git a/spike/hst/scheduler/defpackage.lisp b/spike/hst/scheduler/defpackage.lisp 
index 983666d..47f1a9a 100644 
--- a/spike/hst/scheduler/defpackage.lisp 
+++ b/spike/hst/scheduler/defpackage.lisp 
@@ -118,6 +118,7 @@ 
    #:add-user-package-nickname 
    #:add-value-criteria 
    #:add-vars-from-proposal 
+ #:add-visit-resource-pcf 
    #:add-window-to-gs-params 
    #:adjust-derived-resources 
    #:adjust-links-candidate-criteria-types

這是我們的一個包定義文件，但相關的源文件反映了類似的東西。有誰知道這裏會發生什麼，以及我如何能找到我想要的信息？這並不重要，但這種事情讓我有點緊張。

來源

2010-05-13 asm

這些差異看起來並不一致 - 「添加提議從提議」行是在一個而不是其他。兩人之間確實發生了其他事情？ – Cascabel 2010-05-13 20:21:04

'git bisect'說什麼而不是給你提交？ – che 2010-05-13 20:26:18

@jefromi - 你是正確的，事情發生在兩者之間。我顯示'git log -S'add-visit-resource-pcf'...'的結果，它顯示我在提交日誌或比較中包含「add-visit-resource-pcf」的提交。 @che git bisect確實給了我一個提交，但隨後的提交仍包含應該在我的搜索工作正常時應該被刪除的代碼。我想我或者找不到正確的提交，因爲在提交時存在並行分支給了我這也是我在這份工作上的第一週，而且我對代碼庫基本沒有太大的瞭解 – asm 2010-05-13 21:48:59

我懷疑你可能有一個邪惡的合併 - 一個合併提交，使實際的變化。也許這是一個無辜的錯誤，作爲解決衝突的一部分。假設這是發生了什麼，讓我們看看如何找到它...

git log -Sstring似乎並沒有妥善處理邪惡的合併。（不幸的是git log --cc -Sstring不相信它在他們正確地看，它只是選擇所有合併提交）

有了這個障礙，我能想到的兩個選項：

手動測試合併提交
Kludge自己的log -S：搜索git log --merges -p -cc的輸出爲目標行。它應該看起來像-- #:add-visit-resource-pcf，儘管最快的方法可能是管道到less並搜索add-visit-resource-pcf。

這個故事的寓意當然是邪惡合併被稱爲邪惡。

順便說一句，我很驚訝你沒能找到它與平分線。我非常確定bisect能夠提供合併提交作爲結果。

來源

2010-05-13 20:32:53 Cascabel

感謝你的想法，明天我會試試。 – asm 2010-05-13 22:02:51

謝謝Jefromi，我找到了使用kludge方法退出的合併提交。 – asm 2010-05-14 11:34:25

git不顯示代碼被刪除的地方

回答

相關問題