[f1shy]

Always squashing is a terrible idea. Where I work are some that insist in doing that, and already dozens of times we have los valuable information. Let me quasi-cite somebody with some knowledge about git:

Linus Torvalds generally prefers not to squash commits when merging pull requests into the Linux kernel, especially when the individual commits have valuable information or context. He believes that squashing can discard useful history and make it harder to understand the evolution of the code. However, he also acknowledges that squashing can be useful in certain situations, such as when dealing with a large number of commits that are not relevant to the main development history

[scottgg]

I reckon that nice commits breaking up a big PR that can be merged straight to main is the best outcome.

But - I also think that always squashing is a natural reaction to "twiddling with the past" being difficult (but possible!) with git - e.g., you start with good intentions, you have your nice commit messages, but inevitably you need to go back and make some changes to changes and the "chore: unfuck it for real this time" style "fixup" commits start creeping in and you throw your hands in the air in despair rather than dare to cross `git rebase` once more.

[claytonjy]

I used to like allowing squashing or fast-forward merges. Most PRs would be squashed, because most developers write terrible commit messages and use merge where they could rebase. But, if you had a well-crafted set of commits, we could retain them.

I’ve recently switched to using conventional commits and release-please everywhere, but that pretty much forces us into a squash-only world, since even the devs who write nice commit messages don’t want to make each commit a conventional commit; much nicer to do it as the PR title, and more visible