>It is a luxury we can live without. Do you really suggest to revert JUnit4->JUnit5 change and redo it? Have you tried that? The source history would look insane as it shows that "the revert" commit was the latest commit touching the test codebase.
1) Maintaining a pull request **often** requires multiple force-push operations before the PR can be merged. For instance, Graham used force-push 4 times during JUnit5->JUnit4 development: https://github.com/apache/jmeter/pull/524 force-push enabled Graham to preview how the changes land on top of the current master, and it was possible to have a clean history. PS. I don't like that the commits were squashed into a single one on merge. Basically there were at least 2 distinct types of changes: mechanical (package renames) and meaningful (conversion of non-trivial classes) In other words, rebase+force-push enabled Graham to see the changes as if the changes were originally developed on top of a bleeding-edge source. 2) Here I configure Appveyor: https://github.com/apache/jmeter/pull/529 Even though it is a single-file change, I force-push a lot so the final commit looks sane. 3) You do not have to use force-push when pushing code to the master branch. On top of that, even if force-push is allowed, it is **not** something Git would use by default. The default mode is **not** force. 4) One can easily mess Git history even without force-push operations. One can push regular commits that contain half-baked code. 5) Of course, the one who uses force-push can mess the history. However, 5.1) Trivial recovery is always possible. ASF sends commit ids "before and after", so the force push can **easily** be reverted. 5.2) Even if ASF misses the mail (which it must not), there are lots of forks to recover from. At least there's one at the development machine which was used to initiate the force-push. 5.3) In 99.99% the recovery won't be required provided force-push was "sane" Vladimir
