Version control mercurial'；当范围包括分支时，s对分工作？

如果对分范围包括多个分支，hg bisect的搜索如何工作。它是否有效地将每个支行一分为二（我认为这是低效的）

例如，怀着感激之情，借用一张来自答案的图表，如果对分首先到达“good”右侧分支上的变更集7怎么办

@  12:8ae1fff407c8:bad6
|
o  11:27edd4ba0a78:bad5
|
o    10:312ba3d6eb29:bad4
|\
| o  9:68ae20ea0c02:good33
| |
| o  8:916e977fa594:good32
| |
| o  7:b9d00094223f:good31
| |
o |  6:a7cab1800465:bad3
| |
o |  5:a84e45045a29:bad2
| |
o |  4:d0a381a67072:bad1
| |
o |  3:54349a6276cc:good4
|/
o  2:4588e394e325:good3
|
o  1:de79725cb39a:good2
|
o  0:2641cc78ce7a:good1

那么它会不会看起来只在7到12之间，错过了我们关心的真正的第一个坏消息？（因此使用“哑”数字顺序）或者使用完整地形并知道第一个坏值可能在右侧分支上低于7，或者仍然可能在左侧分支上的任何位置是否足够聪明

我的问题的目的是（a）只是为了更好地理解算法，以及（b）理解我是否可以自由地扩展我的初始对分范围，而不必费劲地思考我要去哪个分支。在每次测试后，它都会要求我扩展到下一次合并之后，所以整个过程基本上都是O（n）。我想知道我是否可以在不考虑太多的情况下，将第一个“好的”标记扔回一些嵌套的合并，以及这样是否可以节省时间并给出正确的结果。

引自：

hg-bisect命令知道Mercurial的“branchy”性质 项目的修订历史记录，因此处理它没有问题 在存储库中分支、合并或多个标头。它可以修剪 整个历史分支都用一个探针，这是怎么回事 运作如此高效

---

执行这项工作的代码位于中，并且实际查看状态已确定的每个节点的后代树和祖先树

在我看来，选择测试的变更集是通过在尚未测试的变更图中加权“中心”来选择的（即按祖先与非祖先平分，而不是按时间顺序）：

108     x = len(a) # number of ancestors
109     y = tot - x # number of non-ancestors
110     value = min(x, y) # how good is this test?