4

我有一个使用“主干”流的存储库，其中功能分支合并并创建合并提交，并且正在使用 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?
4

1 回答 1

2

在 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将继续被跳过。

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

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

于 2020-08-27T06:03:03.770 回答