How can I Git bisect where a bad commit is an ancestor of a good commit / find the fix commit?

I have the following situation:

1. A bug was reported long ago at commit 0badcommit in the project, and it went unnoticed.
2. When cleaning up tickets recently, this ticket was found, but the issue no longer exists on the latest main branch.

I want to find which commit led to fixing of this particular issue. But, git bisect won't let me do it, because the bad commit is ancestor of the good commit.

I get

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?

Is there a way to reverse the bisect logic? Is there something else I can do to find out what commit accidentally fixed this issue?

In addition to the great suggestion in 1615903's answer, 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 brain freeze 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

Actually, after digging man page 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 man page:

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.