git 不显示代码被删除的位置
因此，我的任务是替换我们的项目出于历史兼容性原因所需的一些虚拟代码，但自上次发布以来，这些代码已神秘地删除了。由于消失的代码让我对可能丢失但未被注意到的其他内容感到紧张，因此我一直在挖掘日志，试图找到在哪些提交中删除了这几行。我已经尝试了很多东西，包括“git log -S'add-visit-resource-pcf'”，gitblame，甚至 git bisect 与一个脚本，该脚本只是检查该行是否存在，但无法查明正是这些线被删除的地方。我发现这非常令人困惑，特别是因为在我重新引入此代码之前的最后一个日志条目（通过上述命令获得）也是其他人添加了代码。
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
这是我们的包定义文件之一，但相关源文件反映了类似的内容。有谁知道这里会发生什么以及我如何找到我想要的信息？这并不是那么重要，但这种事情让我有点紧张。
So I was tasked at replacing some dummy code that our project requires for historical compatibility reasons but has mysteriously dropped out sometime since the last release. Since disappearing code makes me nervous about what else might have gone missing but un-noticed I've been digging through the logs trying to find in what commit this handful of lines was removed. I've tried a number of things including "git log -S'add-visit-resource-pcf'", git blame, and even git bisect with a script that simply checks for the existence of the line but have been unable to pinpoint exactly where these lines were removed. I find this very perplexing, particularly since the last log entry (obtained by the above command) before my re-introduction of this code was someone else adding the code as well.
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 relevant source file reflects something similar. Does anyone know what could be going on here and how I could find the information I want? It's not really that important but this kind of things makes me a bit nervous.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我怀疑你可能有一个邪恶的合并——一个进行实际更改的合并提交。也许这是解决冲突过程中的一个无心错误。假设发生了这种情况，让我们看看如何找到它......
git log -Sstring 似乎无法正确处理邪恶合并。 （不幸的是 git log --cc -Sstring 并不能说服它正确地查看它们；它只是选择所有合并提交。）
有了这个障碍，我可以认为两个选项：
手动测试合并提交
整理自己的
log -S：搜索git log --merges -p的输出-cc表示目标行。它应该看起来像-- #:add-visit-resource-pcf，尽管最快的方法可能只是通过管道传输到less并搜索add-visit -resource-pcf.当然，这个故事的寓意是，邪恶的融合被称为邪恶是有原因的。
顺便说一句，我很惊讶你没能用平分法找到它。我非常确定 bisect 能够提供合并提交作为结果。
I suspect you may have an evil merge - a merge commit which makes an actual change. Perhaps it was an innocent mistake as part of conflict resolution. Assuming this is what happened, let's see how to find it...
git log -Sstringdoesn't seem to deal with evil merges properly. (And unfortunatelygit log --cc -Sstringdoesn't convince it to look at them properly; it just selects all merge commits.)With this handicap, I can think of two options:
Manually test merge commits
Kludge your own
log -S: search the output ofgit log --merges -p -ccfor the target line. It should look like-- #:add-visit-resource-pcf, though the quickest way is probably just to pipe tolessand search foradd-visit-resource-pcf.The moral of the story is, of course, that there's a reason evil merges are called evil.
I'm surprised you weren't able to find it with a bisect, by the way. I'm pretty sure bisect's capable of giving merge commits as results.