问题描述
我有一个存储库，该存储库使用带有功能分支的“树干”流进行合并并创建合并提交，并且正在使用bisect尝试查找引入问题的时间。问题识别过程涉及对已知良好提交的结果进行比较，因此我使用git bisect --first-parent（2.29中的新增功能）跳过不在“ trunk”分支中的提交（确定引起问题的合并提交是对我来说足够）。
但是，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 @ 47f0f94bc7中，如果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开始并合并到其后的其他分支将继续被跳过。
虽然我相当确定这是“正确”的行为，并且在大多数使用情况下，用户不会注意到有什么不同，但是手册页可以使用此行为的详细信息和/或在{ {1}}提交仅作为第二个父级存在。
之所以发生这种情况，是因为我们在某个时候“重新批改”了，提交同时进入了两个分支。