Post #1953558

@cas @sbysb Those two flows are not incompatible. You can have sensible commit messages describing individual logical changes, and a PR describing a group of related changes. It's exactly the same as the cover letter model. If your commit messages are essentially worthless and you rely on the PR description to actually describe what is going on, then the solution is to hit the "squash" button instead of the "merge" button and promote the PR description to a single commit message. I think that once you're collaborating with others, a messy commit history has negative value. The tiny commits are useful ephemerally during development, but not as a historical record. It's better to have larger commits with good documentation than it is to have meandering small commits which hardly make sense on their own. Just squash. That's also very important because PR descriptions are often lost. You don't want important information about code history to exist only in the forge database. Squashing also makes rebasing and pulling patches out easier, especially if the development process involved trying and redoing things to any extent. Having commits that revert portions of each other in the history is actively harmful in this case. Essentially, if your PR model involves reviewing the "global changes" view, you want to squash. If you review individual commits, you don't.