i think one rule of thumb to follow is to keep each diff focused. making a functional change? e.g. adding a new feature / fixing a bug? don't try to clean up n

i think one rule of thumb to follow is to keep each diff focused. making a functional change? e.g. adding a new feature / fixing a bug? don't try to clean up neighbouring patches of code, just make the change in a way that is easy to review refactoring / cleaning up code / changing namespaces in 1000 files? don't make functional changes! trying to review a diff that has superficial changes to 1000s of files and also a few hidden surprise functional changes is a complete nightmare. note: just because the revision history should be cleanly separated like this, doesn't mean you have to work like this. you can make interleaved functional changes and refactors when you are working locally - you just need to use your version control's history editing capability to tease apart / re-order your changes and commit them separately.