Organizing your changes for pull requests

Changes to existing code may introduce new bugs.

When we discover a bug, we're using git-bisect to find the commit responsible for the bug.

When looking at the commit diff (usually I use git-show), I want it to be readable -- that is, I want to see what's changed. This means, that code-changing commits should not move large blocks of code around, change indentation, etc.

So, before committing, run git diff, and make sure that the diff is as minimal as possible. No moving code around, no changing indentations of large blocks, etc.

If you need to change indentation, or move a block of code around - do it in a separate commit, and (preferably) separate pull request. Don't squash refactoring commits with code change commits.

The same rules apply when making pull requests. When I'm looking at the PR diff - I want to see the actual changes against the previous version, and/or against my tree.

If you indent or move blocks of code around - all I'd see would be large sections of removed/added code, without any correspondence.

Try reading your own diff, and see if you could understand what has changed.