> How anyone could even hypothetically arrive at this result is beyond me.

Most of the time bugs are fixed shortly after they are introduced. So there's few commits between the last known good version and first known bad version. So people can intuitively check some version in between and do bisect that way, exploiting their knowledge to cut some steps. For example if there's 8 commits but 5 of them only change modules that have nothing to do with the bug.

Also if these 8 commits are very small you can treat them as a whole and look at all their changes at once when searching for the bug (and git blame to see the reason for change in particular line).

It's a great tool when I need it, but 99% of the time I don't.

Thanks for clarifying.

> So people can intuitively check some version in between and do bisect that way, exploiting their knowledge to cut some steps

If you have a hypothesis you hold with enough weight to validate, bisecting in general (let along git bisect) isn't even in the picture yet. The strategy really only enters the picture when you've exhausted any strong hunches and need to debug more systematically.

> and do bisect that way

In context you're not actually describing bisecting.

But taking 'bisect' here as 'bisect': git automates bisecting through the commit history to a greater (with `run`) or lesser (without it) extent. Once you've paid that 15-minute fixed cost of familiarization, `git bisect` is strictly less time- and cognitive-energy-intensive than the manual alternative.

I understand what bisect does. I even used it a few times. I'm jut saying it's very rarely useful in my experience (YMMV).

> How anyone could even hypothetically arrive at this result is beyond me

Well, for a handful of commits, it's very easy to do a "manual binary search" for the commit that caused a bug. Not the OP but that's how I read the comment.