Cleaning up history to be readable, clean and represent the actual net change to the project instead of every dumb error I made is gold.<p>A properly managed history is a <i>huge</i> difference when it comes to dealing with code submissions.  I tend to not take lists of changesets that include a bunch of "oops" because they take me a long time to figure out what the user actually did.<p>In some cases, I have <i>really</i> long lists with really small net changes but a whole lot of experimentation in the middle.  I can't take those.  They rewrite the entire history of giant chunks of the code to put this guy's name on them because he changed something and then changed it back and then committed half a change and then committed the second half, etc...<p>You say, "but this is fine, it's how he worked!"  Then you have to track down a bug and see that it occurred in the middle of this "experimentation phase."  That's when you realize that you don't care at all about the method of discovery, but really wish you could just hear what the discovery was in one changeset that is as small and clean and well-thought-out as possible.