Hi,
The other one is that apart from git history that gets broken immediately there is another consequence which comes later - accepting low quality or questionable patches
I don't think we're talking about low-quality or questionable patches in that case. The examples shared by Andrey show the variation of patches and the possible reactions: There are questionable patches (technically unsure) that are still questioned (value/risk) and discussed before being merged or not; and there are the simple format/style/readability/... changes that pollute the history but still are (at an extremely low rate) valuable technically or in term of future maintenance. The discussion focuses on the 2nd type I guess, for the 1st type, the Eclipse Platform contributor are all doing their best to keep quality good and project sustainable and if you look at how code-reviews are done, you see how everyone make effort for higher quality and less questionable changes.
Indeed, that's something we need to keep in mind and avoid too. I believe and hope this case was really exceptional and that the cultural and process changes in collaboration (preliminary code reviews, diversification of the team, introduction of less expert contributors as committers, more distributed control...) are now complete so no-one would feel shambled by too much change again.
But it's also quite important to remind that any committer is free to disagree or even rant (politely, nicely and in a positive manner) about another piece of code or contribution; and that they shouldn't wait before it's too late and they burn out before mentioning their concerns with other committers and probably the PMC so it can be evaluated whether there is something to improve in the process to fit everyone better.
