Git doesn't show where the code was removed

So I was tasked with replacing some dummy code that our project requires for historical compatibility reasons, but mysteriously dropped out since the last version. Because the disappearing code makes me nervous about what else might have gone missing, but not noticing that I was digging through the logs trying to find what captured that part of the lines. I've tried several things including "git log -S'add-visit-resource-pcf", git blame, and even git bisect with a script that just checks for a line, but couldn't figure out exactly where those lines were removed. I find this very perplexing, especially since the last log entry (obtained by the above command) before I reintroduced this code was someone else adding the code.

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

      

This is for one of our package definition files, but the corresponding source file reflects something similar. Does anyone know what might be going on here and how can I find the information I need? It's not really that important, but things like that make me a little nervous.

+2


a source to share


1 answer


I suspect you may have an evil merge - a merge that makes the actual change. It may have been an innocent mistake as part of the conflict resolution. Assuming it happened, let's see how to find it ...

git log -Sstring

does not seem to deal with evil by merging properly. (And, unfortunately, git log --cc -Sstring

doesn't convince him to look at them correctly, he just selects all merges.)

With this disadvantage, I can imagine two options:



  • Manually merge merge

  • Customize your own log -S

    : find the output git log --merges -p -cc

    for the target line. It should look like -- #:add-visit-resource-pcf

    , although the fastest way is to just go to less

    and search add-visit-resource-pcf

    .

The moral of the story is, of course, that the reason why evil merges is called evil.

I'm surprised you, by the way, couldn't find it with a bisector. I'm pretty sure bisect is capable of producing commits as output.

+4


a source







All Articles