git-via-email workflow tip:

On GitHub, many users will push several commits to their branch to build up one cohesive change gradually, with bug fixes, style fixes, and so on, along the way. In this workflow, the pull request itself acts as a container for the entire change, rather than each commit.

Technically this isn't a great habit for GitHub either, but with email the drawbacks are particularly stark. Trying to replicate this flow for email will have you sending a bunch of "fix typo" commits to a mailing list, entering them all into the record forever. Instead, so long as your original patches are unmerged, you should go back and rebase them to merge bug fixes into earlier commits. Accordingly, you shouldn't take your changes upstream until they're good and ready and tested, as to minimize this churn. Good commit discipline is especially important for email-driven projects.

If you need a refresher on rebasing: https://git-rebase.io

Learn to change history with git rebase!

@sir
"He who controls the past commands the future. He who commands the future conquers the past." - "Kane" (c&c)
@sir
I somehow thought a Command & Conquer quote fitting...