Surely it isn't a great idea once "the" repo has a copy of the dodgy commit, though? Because once everybody else has a copy of it, the history hashes will include it, and removing it with a rebase is going to become more bothersome.
(N.B., I am English - by "bothersome" what I suppose I actually mean is "a massive pain in the arse". Because everybody is going to have to take all their commits since the dodgy one and rebase them on top of the new history. Maybe I should rephrase that to "a massive pain in the fucking arse". But it's always possible there's some git magic I'm not aware of.)
Generally it is not a good idea. But sometimes one has to admit having fucked up, put a marker on an old branch to let people know it's fucked and clean things up. Especially when the alternative is "break half of git's tools by injecting revert + revert-revert".
If i am understanding you right you seem to consider the act of rebasing itself to be "a massive pain in the arse".
In a culture where rebasing of feature branches is considered mandatory anyhow, rebasing a feature branch sideways onto a new unbroken master branch is nothing out of the ordinary and quick and easy.
