If you were bisecting a rebase workflow and hit a block of commits that were unbuildable and unbootable close to your breakage, I'm unsure how you would progress.

But the case is likely better in the merge workflow, since in all likelihood you could mark the entire tree as good, and it could stop searching all ancestors. Which is far more likely to be correct in a merge workflow.

I feel like it's most likely that bisecting the linux kernel was in-fact the shotshow.

Edit: upon further research, it appears that git bisect is a commonly used and useful tool in the kernel, and the correct response to landing in that branch would be `git bisect skip` which should be far more informative to the algorithm then a skip in a linear history https://nathanchance.dev/posts/working-with-git-bisect/