> The reason why I prefer squash commits is not only the linear history but also the fact that I’m simply not interested in the sausage making process.
I see this a lot and in my opinion squash on merge is just a very poor version of using rebase to put your commits into a proper state before merging.
A commit should be one logical set of changes. It's great if you can get a piece of work done in one change, but often larger work requires several changes.
Beginners seem to treat pull requests as places to pile commits until you get something reasonable at the end (the sausage making process). A better way is to curate your work and clean up the individual commits as changes are requested in review. Then you have a coherent history with commit messages that might tell you something useful.
There is another angle I forgot to mention. That is that I also want that each commit can be compiled (depends on the project obviously) and is tested and won’t fail tests. That is super hard to achieve when only testing the last commit of a PR through a push. I mainly want that to help when bisecting. That’s what I achieve by smaller PRs. But again I personally prefers this and lay out my projects and tasks in a way that this actually works for me. I’m not Dogmatic and see the reason for different strategies.
I see this a lot and in my opinion squash on merge is just a very poor version of using rebase to put your commits into a proper state before merging.
A commit should be one logical set of changes. It's great if you can get a piece of work done in one change, but often larger work requires several changes.
Beginners seem to treat pull requests as places to pile commits until you get something reasonable at the end (the sausage making process). A better way is to curate your work and clean up the individual commits as changes are requested in review. Then you have a coherent history with commit messages that might tell you something useful.