Its one of the most important things in open source dev that very few devs focus on. I blame github. This is one of my favourite posts on the git mailing list:

Projects which switch to GitHub tend to have overall commit quality go down IMO, because the system

(a) makes it nearly impossible to review commit messages, so people eventually degrade to writing really bad ones

(b) makes it nearly impossible to review a rebased set of changes except redoing the entire review from square one, so people don't rebase

(c) punishes both users and reviewers who want to work with a rebased patch series by displaying the series out of order -- even for a completely linear history (it resorts based on author timestamp, not even committer timestamp), and

(d) punishes reviewers/users when they attempt to review individual commits by making it harder to see and follow these comments (though it has gotten much better on this front).

There are combination effects too. People to write really bad commit messages for all the additional "fixups" they have.

People notice that commits don't bisect nicely, and instead of understanding that the broken code review system they wrote was the problem, they instead offer a new "squash merge" option, thus destroying all the carefully separated commits that help people understand the individual steps toward the new feature and making it impossible for anyone in the future to review it incrementally.

You may say it's a workflow choice for some people to just squash all their stuff together at their option, which would be fine, but the problem is most developers don't take the time to think, and someone in charge of the project notices that they keep getting un-bisectable meaningless commits unless they force *everyone* in the project to use squash merging.

Now they are punishing me for creating clean separate commits and forcing them all to be squashed -- all as an ugly workaround to the basic tool being *broken*.

You can work around this by making a long sequence of PRs, one per what you intend to be a commit, and try to track the hierarchy -- something that GitHub certainly doesn't make easy.

And then each PR becomes a trivial small change, and you are back to merging individual commits, and writing your own tools to manage a hierarchy of PRs...and reviewers hate you if you do that because it's extremely onerous on them.

GitHub PRs aren't just hard to use, they literally degrade the quality of the code for people who have to use it. I've seen it happen with many projects.

https://public-inbox.org/git/CABPp-BG2SkH0GrRYpHLfp2Wey91ThwQoTgf9UmPa9f5Szn+v3Q@mail.gmail.com/