So much this. Especially if you are squashing PRs, this tool is barely useful. I once tried to bisect the problem and I was able to narrow down the PR that introduced the bug, but the PR was made up of hundreds of commits squashed into one. So, we knew what PR it happened in, and it wasn't surprising because the PR touched dozens of files and hundreds, if not thousands of lines. The PR was a landing PR, in that people opened PRs into a staging branch and then eventually merged that one into the mainline.

If the commits weren't squashed, we could have narrowed down to the individual commit that introduced the (revenue affecting) bug and probably fixed the issue relatively quickly. IIRC, any git-bisect shouldn't take more than ~12ish attempts to find the breaking commit, no matter how many commits there are. At least we knew which PR the issue was affected by, but instead of just hot-fixing what was probably a one-liner, we had to either revert the entire new feature or read through all the changes to find the issue.