我遇到了主线 Linux 内核的问题，我想找到引入 git-bisect 的错误的提交，以通知作者他的更改引入了错误。
\n\n我发现了一个好的和一个坏的提交并开始了二分。好的提交是那些还没有 bug 的提交，坏的提交是那些已经引入了 bug 的提交。Linus 树的最新拉取仍然存在该错误，因此我认为该错误尚未修复，因此我认为通知作者很重要。
\n\n然而，当我进行二分并继续测试所有提交时（没有使用 \xe2\x80\x9egit bisect skip\xe2\x80\x9d 跳过提交，所有这些都被评估为好或坏） ，有一次 git 给我带来了以下消息，让我感到惊讶：
\n\nThe merge base 7089db84e356562f8ba737c29e472cc42d530dbc is bad.\nThis means the bug has been fixed between 7089db84e356562f8ba737c29e472cc42d530dbc and [02c3de1105228e367320e7fdeffbf511904f398c 6d04dfc8966019b8b0977b2cb942351f13d2b178 7aa7d608112baf63a0b1278955f9619427373807].\nGit 不允许我从这一点继续前进。我不明白这一点。我知道不同的分支经常被合并（特别是在 Linus 的树中），并且错误很可能是在侧分支中引入的，但即使是这样，我认为我应该能够识别引入错误的提交，即使如果那是合并提交。为什么在列出的提交之间该错误已被修复，而当我从最新的提交构建时仍然存在问题？
\nGit 源代码树中的文档文件对此进行了深入解答。本质上，Git 告诉您，根据您的测试用例，您自己的分支上的代码是错误的，并且它从某些功能分支分离之前继承了该错误。该错误随后在功能分支中得到修复。同时：
\n\n\n\n\n为什么在列出的提交之间该错误已被修复，而当我从最新的提交构建时仍然存在问题？
\n
出现这种情况有两个明显的原因：
\n\n情况 2 在这里的可能性更大，修复可能很简单\xe2\x80\x94，也可能很复杂\xe2\x80\x94，因为“我们认为这个其他功能 W 已经准备好了，然后我们决定它还没有准备好，并将其恢复为feature/X 分支，然后我们把它放回去，因为现在它已经准备好了”\xe2\x80\x94 并且它的 feature/W 本身会导致错误，这样错误就会在 feature/X 提交跨度期间消失哪个功能/W 被恢复。
\n\n（在某些情况下，错误被意外修复，然后同样意外地重新引入。这在具有一些不稳定属性的算法中很常见，没有人认为这些属性很重要，但实际上却很重要。例如，某些排序算法不稳定\ xe2\x80\x94 不保留正在排序的项目列表中“相等”项目的顺序\xe2\x80\x94 和其他项目。如果所有排序键都是唯一的，则排序的稳定性是无关紧要的。如果您的bug 与非唯一的排序键相关，那么实际的 bug 可能是排序不稳定，或者键本身是错误的，并且 bug 不是您想象的那样。）
\n