> a rewritten history consists of commits nobody generally tried out I find the exact opposite to be true. When you merge 20 commits from a branch, you add to

> a rewritten history consists of commits nobody generally tried out I find the exact opposite to be true. When you merge 20 commits from a branch, you add to the history a bunch of unfinished-state checkpoints, which may not even compile individually, and that may make the search longer than it should. Also, those intermediate commits probably never were deployed as individual units. In a merge-squashed main branch all commits: * were reviewed as a single unit, but may have originated from multi-commit branches * are guaranteed to have passed the test suite * by definition, are at a ready-to-deploy state, even if they contain feature-flagged components These are much easier to bisect through. And their changeset shouldn’t be any larger than any regularly-merged branches. It’s the same unit of work, merged differently. If the PR is too large, then you’re probably lumping too much stuff together, which also leads to slower and worse code review cycles.