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