Rewriting history was the motivation behind commit-patch [1]. Granted, it doesn't actually let you rewrite history per-se, but it allows you to selectively check in parts of a file, which is very similar--You're effectively saying, "checkpoint this portion of a file, even though I've not really ever had the file in this particular state". It allows nice, fine grained commits even on version control systems like CVS and SVN.
> In svn you don't even have the possibility to refuse them.
Too true. One thing we did to try to fix the trashy commit issue was to mail out patches of each commit to a team mailing list. That allowed 2 things to happen:
First, just seeing your trashy commit next to a commit to which someone has payed attention motivated you to be a little more careful next time. If you're just sending your commits into the void you behave differently than if you know what you commit will have a bunch of eyes on it.
Secondly, anyone on the team could just reply to the email and suggest that it be split in 2 commits next time.
> In svn you don't even have the possibility to refuse them.
Too true. One thing we did to try to fix the trashy commit issue was to mail out patches of each commit to a team mailing list. That allowed 2 things to happen:
First, just seeing your trashy commit next to a commit to which someone has payed attention motivated you to be a little more careful next time. If you're just sending your commits into the void you behave differently than if you know what you commit will have a bunch of eyes on it.
Secondly, anyone on the team could just reply to the email and suggest that it be split in 2 commits next time.
[1] http://porkrind.org/commit-patch