Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git bisect`ing things later.

They are also necessary to keep a history where `git blame` can be used effectively.

Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ?

I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick.

As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!

On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.

Sure but I think OP was advocating rebasing a shared branch so that git bisect would always pass on each commit

git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.

You usually won't lose commits with reflog, especially the more users of a repo the more reflogs.. but yes a disaster to go find them again...

As long as you can communicate the change to other branch users, I don't see the problem?

Oh, for sure. I use it all the time. There's no doubt `git push -f` is useful. Even less doubt that it's dangerous. ;-)