Pre-push commit history is purely for the developer. A push is a publish, which means you are now presenting work for others to view and understand, code review, maintain, and use to debug. There is no more value to people to see every commit for a typo-fix, rollback, and redirection than there would be if our text files kept a complete and honest history of your every backspace. Nobody else wants to watch the rambling movie. BUT that movie can be important to you for a time, and can remain on your local git repo.
If the commit history is getting long in the tooth, it does help to clean it up fairly often, and I have found that cleanup for long-running branches to be much more valuable to my memory than trying to walk or bisect through every minute of my development process.
A quick note about merges: A merge should have something more interesting than "developer merged branch foo onto master"; a merge introduces something important, and old branch names may not exist in the future at all or on the same commits. If one follows this rule of thumb -- make commit messages useful -- then the fact that you were updating your branch with the latest master becomes unimportant. It is actually noise and confusion for anyone having to dig through commit histories, due to the massive number of forks. In other words, always rebase onto master first before merging.
I look at commit history as a document that I can polish and present to others. I look at my code the same way, trying to make it readable for other humans. This is writing prose. I group like things together. Each commit is a solid microfeature. There are no typo commits.