I was thinking of writing this blog post too. Maybe I still will, because I want to emphasise something different about this topic. Mailing list workflows also

I was thinking of writing this blog post too. Maybe I still will, because I want to emphasise something different about this topic. Mailing list workflows also make people write a different sort of commit, where the diffs are short and readable and the commit messages are persuasive as to why the diff should be accepted. That's because these diffs and commit messages are going to be much more prominent in people's mailboxes, so both should be as readable as possible. Extraneous things such as style fixes or whitespace changes within the same diff are frowned upon because they bring clutter and hinder readability (it's okay to throw those into a separate commit and thus a separate email, though). I find this style of commits immensely useful when reading the project's history, but their value is hard to convey to someone raised on Github, which strongly discourages this style of commits. Most Github users I've seen never read the project's history, because they value neither writing it nor reading it.