My current understanding is that... "it depends". I like that you identified ground rules/preconditions for aggressive force-pushing. Imagine a scenario for a

My current understanding is that... "it depends". I like that you identified ground rules/preconditions for aggressive force-pushing. Imagine a scenario for a large team (think kernel). Chat logs of a team developing some feature look something like: A: Ok, I have finished with issue1, check out commit abcd1 B: Hm, does not work for me. Looks like race condition in foo.c, fixed in abce2. Going to sleep. C: You broke init_foo(), reverted in qwer3 A: Ok, modified init_bar() works on my machine, check dvor4 C: LGTM Yet release branch contains all those commits squashed into abcd1. Now person B (or anyone else) has no idea whether which versions of init_foo() and init_bar() work on their machine and what to fix. We sometimes tend to forget (and tools like github/gitlab help with that) that not only git, but the whole workflow might be distributed and changing history in one place might desync it with other places. I think that unless all that history is absolutely unnecessary, e.g. done by a single developer, is extremely well tested, contains loads of "oops" commits, history should not be messed with. That's why all the warnings: git cannot manage all the references to history