Yes, this can be abused to combine a huge amount of work into one monster patch.
But it can be used sanely to re-order and combine patches from a line of development into a clean series of logical patches.
When you are developing something, if you check it in frequently as you go along, you are going to have cases where you introduce a bug at one point and don't find and fix it for several commits. You are also going to have things that you do at some point that you find were not the best way to do something and that you change back later (but want to keep other work you have done in the meantime)
you now have the option of either pushing this history, including all your false starts, bugs, etc.
Or you can clean the history up, combining the bugfixes with the earlier patches that introduced the bug, eliminating the false starts, etc and push the result.
The first approach has the advantage that everything is visible, but it has the disadvantage that there are a lot of commits in the history where things just don't work.
If the project in question encourages the use of bisect to track down problems, having lots of commits where things just don't work makes it really hard for users trying to help the developers track down the bugs.
As a result, many projects encourage the developers to take the second approach.
Now, many developers misunderstand this to mean that they are encouraged to rebase their entire development effort into one monster patch relative to the latest head, but that's actually a bad thing to do.
And in any case, the history is still available to the developer, they are just choosing not to share that history with the outside world.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds