Git Send Email via Emacs

Sending Email, with patches

I have been considering signing up for Sourcehut for a while, that combined with a recent need to submit some patches via email caused me to invest some time figuring out a workflow to submit patches via Email.

Some interesting things that I hadn't considered, for example, when you create patches via email, they encode the object-id in the diff,

for example

diff --git a/doc/introduction.rst b/doc/introduction.rst
index 1026aae..699be76 100644

This diff has the SHA of the blob 1026aae, and the resulting SHA encoded in the diff header.

$ git ls-tree 5dd1dd7 -- doc/introduction.rst
100644 blob 1026aae2b3222c7ca208951a7f17f5f5ab7cebff	doc/introduction.rst

Patches track the SHA of the objects. Unlike with Pull Requests which are all commit based.

I'm not 100% clear on the impact of this, but I don't think it's going to be safe or reliable to submit patches via git send-email -1 and expect it to work in all cases.

When submitting patches, sometimes you'll find that multiple projects all submit to the same mailing list, in this case you should set a subject prefix.

From within Eshell you can run this to setup the required project prefix

git config format.subjectPrefix "PATCH $(projectile-project-name)"

If you do decide to use git send-email then you'll want to set annotate to yes, this will force the display of the changes before emailing them. This will allow you the chance to edit them if you want to change them, or to add any other annotations after the commit message.

[sendemail]
annotate = yes

For the most important part, threading and sign-off. Threading should be set to shallow. Without this, you'll never be able to submit a patch set.

Lots of projects also require the signOff sections, so setting this to yes, is easy to do and low impact for project that don't require it.

[format]
thread = shallow
signOff = yes

Lots of these tips came from

Once the above is setup, then we can move onto the Emacs side of the configuration.

I'm currently trying to use https://sr.ht/~yoctocell/git-email/ which I have forked here https://git.sr.ht/~rsl/git-email while I wait for the upstream developer to return. It's a library that takes the response from git format-patch and then processes that into a compose-mail buffer.

This works reasonably well, my workflow is for every patch set (or individual patch) to make a separate branch patch.fix-thing for example.

I have 2 remotes on each repository, origin is set to my own mirror of the repository. Then I use the upstream remote to track the upstream. I setup Magit to respect these by setting each branch's remote to upstream and pushRemote to origin

I do this in case I need to make revisions to the patch, if I didn't then I would have to pull down the patch apply it and fiddle around to make this setup, because in the end any change you do to the patch will likely also require rebaseing on upstream.

To make the patch on my new branch, I can use the git-email command's via Magit using the keybinding `W c s` which will then prompt me for a range of commits to send.