Bad commits are the absolute most difficult thing to reverse when they get released and the userbase codes to them. When I don't pay super close attention to what's being contributed, it creates three times as much work after I let it through.
How is that an issue in this day and age? Just run astyle or indent.
"Style" is more than indentation - my favourite example is something I worked with very closely, but always needed a cheat-sheet on my desk - the PHP arrays api.
Just look at the docs for array_search and array_replace.
This is much worse in managed memory languages - do you allocate memory, who frees it, who can use a buffer in zero-copy mode, who can't ... whether the functions are always re-entrant.
All that said - any originating coder who burns out due to support issues, killing the community is measurably worse off than someone who has thousands of users who demand that you support such "legacy" APIs for another six months.
Examples of PRs that "work" exactly as intended yet are the wrong way to solve the problem:
https://github.com/zzzeek/sqlalchemy/pull/381
https://github.com/zzzeek/sqlalchemy/pull/382
Here's a large PR:
https://github.com/zzzeek/sqlalchemy/pull/365
that after lots and lots of back and forth I finally merged with lots of edits from me at: https://github.com/zzzeek/sqlalchemy/commit/7d3da6f850dca54b...
...aannnnndddd - after all that work and testing, it was wrong! Fortunately someone caught the mistake within the beta release:
https://bitbucket.org/zzzeek/sqlalchemy/issues/4072/mysqldml...
if I had released that fully and the whole world coded to "mysql.insert.values.bar == 5", that's broken API since it breaks the values() method. Backwards-incompatible fix required.