[sofal]

This probably comes down to discipline, meaning that when you rewrite history in git you may want to take care that you're keeping the useful bits of it and not just squashing everything down to get fat feature-rich commits. Do you think that the history-rewriting tools in git are too often abused by the average git user such that the use of git in general has the problems you've described?

[azakai]

Not sure if I agree as to what is normal and what is abuse here. If you write some feature in a branch, and have various commits for bugfixes as you go, you might want to merge those little commits away for review as well as for bisection purposes. This seems both normal and desirable to me - no one wants to review a set of 100 patches for a feature if they contain a lot of redundancy. It's useful to do small commits as you work to get a feature stable, but it isn't useful to ask someone to review all those commits, especially if they fix a previous bug introduced by another such small commit.

However, that history can still be very useful: You might hit a variation on those bugs later, and seeing the original unrewritten history can help a lot in refreshing your memory on what you did there (and it can be even more helpful for someone else getting up to speed on the code trying to fix that bug). Losing the history after history rewriting isn't a good thing.

[sofal]

In my experience what is being reviewed by your peers are the feature diffs, not the individual commit diffs. What the actual history looks like is entirely up to you as the coder.