Follow

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: git-rebase.io

@sir
And it also.makes the git history cleaner to whoever will be looking at it (bisecting, git-blaming, etc) later on.

@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...

@sir

~~so how does one find a balance between ‘fix typo’ and ‘my single commit is a massive changelog i still can’t commit because the feature isn’t working yet’~~

@Valenoern @sir A big new feature should be separated into a patchset (so multiple patches) that makes sense chronogically (if possible)

You can still commit often, and use git rebase to better separate your changes into logical patches.

Once good enough, you send the patchset.

@Valenoern @sir

Perhaps not applicable in all circumstances, but make a smaller feature?

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!