This is such an engineer's response to a usability problem. I've worked with quite a few organizations and many of them use squash merges. Commits are often ma

This is such an engineer's response to a usability problem. I've worked with quite a few organizations and many of them use squash merges. Commits are often made because of a failed lint check needs a new formatting commit, addressing some comments to tweak some minor details, or even basic documentation changes. The pull request on GitHub ends up being the source of truth for the change, not the git log, and squash merges do a great job at keeping a single pointer to the parent pull request. Ignoring these nuances and how git interacts with other tools amounts to telling the user they're holding it wrong. Clearly, squash merging does something useful but the author is totally not interested and declares that squash merging is good for one exceptionally specific use case, the only true clean commit history is not using git at all, and the problem exists between the keyboard and the computer.