问题

我有以下情况：

1. 一个bug在项目的提交0badcommit中很久以前被报告，但一直未被注意到。
2. 最近在清理工单时，发现了这个工单，但最新的main分支上不再存在该问题。

我想找出是哪个提交修复了这个特定的问题。但是，git bisect不允许我这样做，因为坏的提交是好的提交的祖先。
我收到以下错误信息：

一些好的提交不是坏的提交的祖先。
在这种情况下，git bisect 无法正常工作。
也许你搞错了好的提交和坏的提交？

有没有办法反转二分查找（bisect）的逻辑？还有其他方法可以找出是哪个提交意外修复了这个问题？

Some good revs are not ancestors of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistook good and bad revs?

答案1

得分: 7

以下是翻译的内容：

In addition to the great suggestion in the other answer https://stackoverflow.com/a/75407777/3715736, we can define our own good and bad "terms" with git bisect which makes it easier to retain the correct context.

For example, in order to define good as bad and bad as good (which gives me brainfreeze after a while), we can do

git bisect start --term-good mybad --term-bad mygood

and then, later on,

git bisect mygood d04eb09ab # for our good but really a bad commit```

**Edit (The correct answer):**
Actually, after digging manpage a bit more, the correct command for the kind of problem I'm trying to solve is to use `git bisect old` and `git bisect new`. These commands will tell you which commit introduced the fix instead of which commit broke things.

From the manpage:

> Sometimes you are not looking for the commit that introduced a breakage, but rather for a commit that caused a change between some other "old" state and "new" state. For example, you might be looking for the commit that introduced a particular fix. Or you might be looking for the first commit in which the source-code filenames were finally all converted to your company’s naming standard. Or whatever.

> In such cases it can be very confusing to use the terms "good" and "bad" to refer to "the state before the change" and "the state after the change". So instead, you can use the terms "old" and "new," respectively, in place of "good" and "bad." (But note that you cannot mix "good" and "bad" with "old" and "new" in a single session.)

> In this more general usage, you provide git bisect with a "new" commit that has some property and an "old" commit that doesn’t have that property. Each time git bisect checks out a commit, you test if that commit has the property. If it does, mark the commit as "new"; otherwise, mark it as "old." When the bisection is done, git bisect will report which commit introduced the property.

<details>
<summary>英文:</summary>

In addition to the great suggestion in the other answer https://stackoverflow.com/a/75407777/3715736, we can define our own good and bad &quot;terms&quot; with `git bisect` which makes it easier to retain the correct context.

For example, in order to define good as bad and bad as good (which gives me brainfreeze after a while), we can do

git bisect start --term-good mybad --term-bad mygood

and then, later on,

git bisect mybad 0c5c211ba # for our bad but really a good commit
git bisect mygood d04eb09ab # for our good but really a bad commit

**Edit (The correct answer):**
Actually, after digging manpage a bit more, the correct command for the kind of problem I'm trying to solve is to use `git bisect old` and `git bisect new`. These commands will tell you which commit introduced the fix instead of which commit broke things.

From the manpage:

> Sometimes you are not looking for the commit that introduced a breakage, but rather for a
> commit that caused a change between some other "old" state and "new" state. For example,
> you might be looking for the commit that introduced a particular fix. Or you might be
> looking for the first commit in which the source-code filenames were finally all converted
> to your company’s naming standard. Or whatever.
>
> In such cases it can be very confusing to use the terms "good" and "bad" to refer to "the
> state before the change" and "the state after the change". So instead, you can use the
> terms "old" and "new", respectively, in place of "good" and "bad". (But note that you
> cannot mix "good" and "bad" with "old" and "new" in a single session.)
>
> In this more general usage, you provide git bisect with a "new" commit that has some
> property and an "old" commit that doesn’t have that property. Each time git bisect checks
> out a commit, you test if that commit has the property. If it does, mark the commit as
> "new"; otherwise, mark it as "old". When the bisection is done, git bisect will report
> which commit introduced the property.

</details>



# 答案2
**得分**: 4

&lt;strike&gt;你不能改变 `git bisect` 的逻辑&lt;/strike&gt; 原来你实际上是可以的，查看其他答案，但你可以改变你自己的逻辑。将旧的引入错误的提交标记为 `good`，将最新的提交标记为 `bad`，然后像往常一样执行二分查找，但将好的提交标记为坏的，坏的提交标记为好的。

<details>
<summary>英文:</summary>

&lt;strike&gt;You can&#39;t change the logic of `git bisect`&lt;/strike&gt; turns out you actually can, see the other answers, but you can change your own logic. Mark the old bug-introducing commit as `good` and the latest commit as `bad`, and do the bisecting as usual, but instead marking good commits as bad and bad commits as good.

</details>