Funny how fast Git became entrenched as the way of doing things, though. Around 2010 I said in passing, in a forum discussion about how a FOSS project was getting along, “…you’d think someone could send in a patch…”, and I immediately got flamed by several people because no one used patches any more.
> Funny how fast Git became entrenched as the way of doing things, though.
It just really highlights how much better BitKeeper and then Git's design was compared to what came before. You then pile on being free/OSS, and being "proven" by an extremely large, well known, and successful project on top, and you have yourself explosive growth.
There are developers around these days who never had the displeasure of using the pre-Git source control offerings; it was rough.
You can use `git format-patch` to export a range of commits from your local git tree as a set of patches. You can then use `git send-email` to send that patch set out to the appropriate mailing list and maintainers (or just do it in one step, send-email accepts a similar commit range instead of patch files). It talks directly to an SMTP server you have configured in your `.gitconfig` and sends out e-mail.
Of course, `git send-email` has a plethora of options, e.g. you'd typically add a cover letter for a patch set.
Also, in the Linux kernel tree, there are some additional helper scripts that you might want to run first, like `checkpatch.pl` for some basic sanity checks and `get_maintainer.pl` that tells you the relevant maintainers for the code your patch set touches, so you can add them to `--cc`.
The patches are reviewed/discussed on the mailing list that you sent them to.
On the receiving side, as a maintainer, you'd use `git am` (apply mail) that can import the commits from a set of mbox files into your local git tree.
For most people, git is that you work with pull requests, and already early on some bristled at the term “patches” which implied an obsolete way of working.
