Squash merges simply guarantee that git bisect will not be able to pinpoint a breaking change, because that history is gone.

If you treat a PR as a unit of work, then there is nothing to bisect. If you don't treat it as a unit of work, then people just edit their git history to merge commits just like a squash.

> If you treat a PR as a unit of work, then there is nothing to bisect.

You're bisecting the history of PR merges.

You ignored the part where I claimed that without squash merging, people will just do it manually with git rebasing or amending.

You listed two cases. One where people do treat a PR as a unit of work, and one where they don't.

I responded to the first case. Of course I ignored a claim you made about the second case. If I didn't ignore that, I would be making a strawman out of what you said, mixing up your words in a way that doesn't make sense.

You're ignoring the part where squashing commits leaves you with fewer, larger commits to search through, while merging or rebasing leaves you with a more fine-grained commit history that allows a git bisect to better narrow down what changes broke something.