二分法以git结束，告诉我合并基不好--我现在怎么能进步？

Question

我在主线Linux内核上遇到了一个问题，我希望找到提交，它引入了git-bisect的bug，以通知作者他的更改引入了一个bug。

我发现了一个好的和坏的承诺，并开始了二分。好的提交是那些还没有错误的人，坏的提交是那些已经引入错误的提交。最近Linus的树仍然有这个bug，所以我认为这个bug还没有修复，所以这就是为什么我认为通知作者很重要。

然而，在我进行二分法的过程中，继续测试整个过程中的所有提交(没有使用“git对齐跳过”跳过的提交，所有这些都被评估为是好的还是坏的)，有一次git让我惊讶于以下消息：

The merge base 7089db84e356562f8ba737c29e472cc42d530dbc is bad.
This means the bug has been fixed between 7089db84e356562f8ba737c29e472cc42d530dbc and [02c3de1105228e367320e7fdeffbf511904f398c 6d04dfc8966019b8b0977b2cb942351f13d2b178 7aa7d608112baf63a0b1278955f9619427373807].

Git不允许我在这一点上取得进展。我不明白这个。我知道不同的分支经常被合并(特别是在Linus的树中)，并且这个bug很可能是在一个侧分支中引入的，但是即使是这样，我认为我应该能够识别引入bug的提交，即使这是合并提交。当我从最近的提交构建时，为什么在列出的提交之间已经修复了bug？

Answer 1

这一点在Git源树中的文档文件中得到了深入的回答.基本上，Git是告诉您，根据您的测试用例，您自己的分支上的代码是错误的，它继承了某些特性分支分离之前的错误。然后，错误被固定在特性分支中。同时：

当我从最近的提交构建时，为什么在列出的提交之间已经修复了bug？

有两个明显的原因可能是这样的：

1. 带有修复的特性分支不是最新提交的一部分。
2. bug可能已经修复，然后重新引入。

案例2在这里可能更有可能出现，而且修复可能很简单--或者很复杂--就像“我们认为另一个特性W已经准备好了，然后我们在feature/X分支中决定没有恢复它，然后我们把它放回去，因为现在它已经准备好了，”-and它本身就会导致这个bug，这样这个bug就会在feature/X提交-跨度中消失。在这个过程中，特性/W被恢复了。

(在某些情况下，错误是偶然修复的，然后同样也是意外地重新引入。这在算法中很常见，这些算法有一些不稳定的特性，没有人认为这很重要。例如，有些算法是不稳定的--在排序的项目列表中不保留“相等”项的顺序，而其他算法则是这样。如果所有排序键都是唯一的，则排序的稳定性与此无关。如果您的bug与非唯一的排序键相关联，那么实际的bug可能是排序不稳定，或者键本身是错误的，并且错误不是您所认为的那样。)

Answer 2

我刚收到了同样的信息。想要平分一个已经固定的问题。我变了

好的/坏的

至

git分新/旧

这让我想到了错误修复提交。