You can send an email with git?

git send-email is a thing?

what is that

From the git manual:

git-send-email - Send a collection of patches as emails

Takes the patches given on the command line and emails them out.

Patches can be specified as files, directories (which will send all files in the directory), or directly as a revision list… the header of the email is configurable via command-line options.

I’ve had cases where I’ve been sent a patch for review directly. This can happen if Github is down or if for some reason we want a commit reviewed before it is added to the central repository.

Sending the patches directly from git sounds handy?

Ok, what are patch files?

They’re commits formatted for sharing via email.

Lets say I want to send a colleague the commits of my work on benchmarking puma vs unicorn (but privately, because I’m ashamed of the hacks).

$ git checkout puma
$ git log

commit 165f336985772d31768424b4042cf5d6d860f32b (HEAD -> puma)
Author: Bill Franklin <[email protected]>
Date:   Thu May 23 09:31:49 2019 +0100

    SPIKE: Benchmark Puma vs Unicorn

Patch files are created with git format-patch, which prepares patches for e-mail submission.

The following turns each new commit to this branch into a patch file within /tmp/patches.

$ git format-patch master -o tmp/patches
tmp/patches/0001-SPIKE-Benchmark-Puma-vs-Unicorn.patch

The contents of the patch file looks very like the output of git diff. At the top of the file are a bunch of headers.

From 165f336985772d31768424b4042cf5d6d860f32b Mon Sep 17 00:00:00 2001
From: Bill Franklin <[email protected]>
Date: Thu, 23 May 2019 09:31:49 +0100
Subject: [PATCH] SPIKE: Benchmark Puma vs Unicorn

Interesting 🤔. So now doing this will work (git prompts for an addressee but otherwise is happy with this):

git send-email tmp/patches/0001-SPIKE-Benchmark-Puma-vs-Unicorn.patch

Better than gmail?

Well.

More features, so

By default you’ll have the archive of what you’ve sent out locally, so you can write scripts, macros, aliases, etc. to your hearts content. Whereas gmail has a very safe UI that doesn’t let you run any old npm script against your email archive…

It also comes with common git features like --dry-run which will do everything except actually send the emails out.

git send-email as a platform

You can use a git repository as an open source email inbox? E.g. git send-email emails/a-spicy-tweet. This might be a fun way to run a mailing list for a blog… perhaps this is what Twitter’s system looks like. Maybe I could make a new version of Twitter based on git send-email.

It even has --chain-reply-to and --thread flags, which will mean all emails get sent as a reply to the previous one (if you’re sending multiple patches). It had threads way before Twitter did. This is better than Twitter.

Use git to send email via gmail

The first example in the manual shows how to use gmail as the smtp server, to send your patches via gmail. Add this to your ~/.gitconfig:

           [sendemail]
                   smtpEncryption = tls
                   smtpServer = smtp.gmail.com
                   smtpUser = [email protected]
                   smtpServerPort = 587

If you have multifactor authentication setup on your gmail account, you will need to generate an app-specific password for use with git send-email. Visit https://security.google.com/settings/security/apppasswords to setup an app-specific password. Once setup, you can store it with the credentials helper:

$ git credential fill
protocol=smtp
host=smtp.gmail.com
[email protected]
password=app-password

So, you can still have Google’s security, spam filters and so on. All from the world of git.

But does it scale?

It’s quite cool one can do this. I’ll try it out next time I need to share a patch.

This feels like a feature that is only useful very rarely.. I’d be interested in hearing from people who use this / or used to use this frequently.

I wonder if central repositories came along and completely ate the lunch of git send-email, since reviewing patches and so on in a centralised manner is surely easier than keeping repositories in sync via email.

Managing projects in the past without a central repo would probably have been quite tricky, especially in a big team. Imagine trying to keep Google’s monorepo in sync!

I was a bit tongue-in-cheek when trying to think of use cases for this. For it’s purpose (sending patches), this is perfect and works as you’d want it to. I probably will end up using it, and I’m glad I know about it. It’s also a nice reminder of how much there is to know about a tool I’ve used every day for years.

Thanks for reading.