I worked as a lone developer for a long time. During this time, I developed a way of formulating and ordering commit messages: Refactor first, describe exactly the reason for the commit in the message, link to the issue tracker, ... There is even a script to create several sorts of change log (public, company-internal, developer) from the commit history. This way I always know, when and why the code in the codebase changed to the state it is now.
With the advent of interactive rebase and commit reordering, I can easily make sure that history (and, thus, documentation) looks exactly the way I want it to be. Bad code doesn't even get into the history. So, every commit has its well-defined purpose.
It took me years to evolve this practice, which I consider a good one. (Is it?) However, applying this to someone else's code changes (i.e., rewriting the history of someone else's changes) is, for me, a painfully time-consuming task. I have tried this in order to identify unnecessary or even faulty changes. The total size of the patch in question is slightly too big to be reviewed as a single unit, and there are a few questionable code changes.
In fact, it turns out that I cannot afford to control the code base as a "dictator". It just costs too much time. So I'd like to lose some control while maintaining a good quality of the code. Currently, I just don't see how to achieve this.
"How clean" should the history of a project be? Which format and granularity for the commits should I require? Should I ask the developer to reformat history (e.g., to split a commit), even if it would require education on how to split a commit after the fact? Should I teach developers to work on feature branches? Can commit templates help? How frequently should the changes by the others be reviewed?