Before committing changes to the version control system, read through a diff of what you've changed.  This helps you:

	* Help the current codebase monotonically improve
	* Make sure you only changed what you meant to change and didn't make any editing misteaks '':)''
	* Write a good ChangeLog that describes why you changed it
	* Throw away your changes if in hindsight they were no good or just futzing, before they get into the codebase
	* Get into a frame of mind where you avoid gratuituous changes: every diff should have a purpose, whether it be adding functionality, documentation, or refactoring
	* Make sure your change list has a single purpose.  If your checkin comment has multiple clauses, then you didn't commit soon enough or you should split your change list.
	* ...and your pair make sure you did the RightThing (reworked hacks, formatted consistently, commented the tricky stuff, etc.)
	* Ensure you haven't reverted someone else's changes (if you're in a situation where the source library can't or won't do that for you).

Contributors: MartinPool, IanOsgood
----
what's "futzing"? -- AndrewCates

"futzing" = fiddling around with no real direction or outcome. -- jt