git bisect 如何选择一个没有第一个好的提交作为祖先的提交？ （使用--first-parent）

Posted 2023-03-24

【中文标题】git bisect 如何选择一个没有第一个好的提交作为祖先的提交？ （使用--first-parent）

【英文标题】：How can git bisect pick a commit that doesn't have the first good commit as an ancestor? (using --first-parent)

【发布时间】：2020-12-15 21:48:46

【问题描述】：

我有一个使用“主干”流的存储库，其中功能分支合并并创建合并提交，并且正在使用 bisect 尝试查找何时引入问题。问题识别过程涉及与已知良好提交的结果进行比较，因此我使用git bisect --first-parent（2.29 中的新功能）跳过不在“主干”分支中的提交（识别导致问题的合并提交就足够了我）。

但是，git bisect --first-parent 正在挑选没有我作为祖先的第一个良好提交的提交，我不确定这怎么可能。

在下面的示例中，提交2 是好的，4 是坏的。

  a 
 / \
1-2-3-4

没有--first-parent，我希望功能分支提交a 包含在二等分中，但是使用--first-parent，我希望它跳过那个提交，只测试合并提交3。

我已经在一个小型存储库上对此进行了测试，它的行为符合我的预期，但是我更大、更复杂的存储库不会跳过没有 first-good 作为祖先的提交，而且我我很难理解为什么。

我的命令是

# both "first-good" and "first-bad" are tags on the "trunk" branch
git bisect start --first-parent
git merge-base --is-ancestor first-good first-bad  # returns TRUE
git merge-base first-good first-bad                # returns first-good
git checkout first-bad 
git bisect bad
git checkout first-good
git bisect good 
git merge-base --is-ancestor first-good HEAD       # returns FALSE - why/how?
git merge-base first-good HEAD                     # returns some other commit - why/how?

【问题讨论】：

git bisect 的第一父模式是新的，可能有错误。如果您有可靠的复制器（最好是短的），请将其发送到 Git 邮件列表。

我可以在伪造的存储库中进行复制，但我观察到的行为在所有情况下都没有预料到吗？或者是否有一些分支/合并策略的组合会使该假设无效。

鉴于我既没有工作也没有使用过新模式，我不能向你保证这是这种情况，但从逻辑上讲，--first-parent 在任何合并时都应该始终跟随第一个父级，因此永远不要测试合并腿上的东西。我想看看这个行为不端的图的拓扑结构。

【参考方案1】：

在 git@47f0f94bc7 中，如果 first-good 提交仅作为合并提交的第二个父项存在于主线中，则会观察到问题中描述的行为。考虑到标志的名称，我想这在某种程度上是意料之中的，但是如果您依赖 first-good 提交来进行工作构建，这确实会导致令人困惑的行为，因为并非所有对分都包含该提交。

例如：

  a - b - c   # "trunk2"
 /   /  
1 - 2         # "trunk1"

# 2 is the `first-good` commit
# c is the `first-bad` commit

git bisect --first-parent 将选择a 作为测试提交，即使它不是第一个已知良好提交2 的祖先。在这种情况下，它似乎回溯到a，这是第一个不是first-good祖先的提交。它不测试1，因为它是first-good 的祖先，因此可以假设它也是好的。

在此示例中，带有或不带有 --first-parents 标志的行为是相同的。从trunk2 开始并合并回trunk2 的其他分支将继续被跳过。

虽然我相当确定这是“正确”的行为，并且对于大多数用例，用户不会注意到差异，但手册页可以使用此行为的一些细节和/或在 @ 时给出的警告987654333@ commit 仅作为第二个父级存在。

这发生在我的例子中，因为我们在某个时候“重新中继”，提交同时进入两个分支。