I get your point about the development process representation, but I don't think you get the OP's point completely, there are ways to get there which do involve

I get your point about the development process representation, but I don't think you get the OP's point completely, there are ways to get there which do involve rebasing. I assume OP works the same way like I work; not every commit represents an interesting part of the development process (more like from the thought process while working) and rebasing afterwards is simply mandatory. By example: this morning I was working on some huge refactoring and already had 5 short meaningful commits (not all with proper commit message yet) when I noticed some small bug creepd in so I added a line to fix it. That line then goes in it's own fixup commit for one of the earlier commits. Likewise, I noticed one of the new interfaces would be better if it had 2 more methods. So: new fixup commit again. A couple of commits later one logical piece of the work was done, so I did a rebase to get all the fixup commits amended to where they belong. Then I reviewed all commits carefully, rebasing again and squashing some commits because it made more sense to me like that, and adding/editing proper commit messages on the go. I work best like this (mainly for pretty large changes or new features which add a lot of code - for small fixes here and there it's obviously not as involved) and it does produce a perfecly viable story about the development process, useful to other readers, but only because of the rebasing. Otherwise it would be a mess. This to illustrate it's not always as simple and general as 'please don't do that rebasing madness'.