Well, someone asked you if rewriting history is ok (but didn't explain the consequences), and you replied that it is ok (though I doubt you understand the consequences), so let's clarify that.
If you rewrite history, then every other user's repository will be broken. Not "broken beyond repair", but broken nonetheless. They'll have to take steps to fix them; and if you want them to fix them "the right way" - which is to say, without undoing your history rewrite - then you'll need to let them know in advance what's happening and what they need to do.
If that still seems ok, and worth the trouble for what you'll gain, then it can be done. I'll go ahead and point out that if I were a contributor to your project, I would not be pleased having the decision forced on me, that extra effort on my part is "worth it" to correct an aesthetic problem that was not of my making.
The situation in which your users will find themselves is described in the git rebase
docs under Recovering from Upstream Rebase. So I'd start by looking that over. When rewriting the entire repository history, my general advice is to have everyone push all of their code to origin and discard their clones, then do the rewrite, then have everyone re-clone; because repairing an old clone after the rewrite is likely to be a serious hassle.
If, in the end, you decide to do the rewrite anyway, you would use git filter-branch
with the --env-filter
argument.