Peter Eisentraut: How to submit a patch by email, 2023 edition

In 2009, I wrote a blog post How to submit a patch by email, which became popular at the time and also ended up in the PostgreSQL wiki. That article was written pre-Git and pre-cfbot, so maybe it’s time for a refresher, as we head into the next PostgreSQL development cycle. The short answer is: Use git format-patch. That takes care of almost all of the conventions and details. Looking at the upcoming commit fests, it appears that the vast majority of patch submissions already use that. But I suspect that in some cases people produce the patches in some other way and then rename them to look like what other people are doing, without knowing about git format-patch? Here is the basic workflow: $ git checkout -b my-feature-branch # hack hack hack $ git commit ... $ git format-patch master 0001-Add-my-feature.patch And if you later update your patch and want to send in a new version, you can do: # hack hack hack $ git commit --amend --reset $ git format-patch -v2 master v2-0001-Add-my-feature.patch (You can also version your first patch as -v1. Or you can try to be optimistic and hope your patch won’t require a second version. ;-) ) You can also split up your submission into multiple commits: $ git checkout -b my-feature-branch # hack hack hack $ git add ... $ git commit ... $ git add ... $ git commit ... $ git format-patch master 0001-Some-refactoring.patch 0002-Add-my-feature.patch Exactly how to split up a submission into commits sensibly is perhaps the subject of another article, but in general it’s something that is encouraged and welcome. Note the following features of what git format-patch produces: Patch files automatically get a descriptive name. Patch files get the correct file extension. Patch files are numbered so they sort easily. When using versions, files belonging to a version sort together. (The alternative manual naming like “my-feature-v2.patch” is therefore wrong.) [...]