Notes
Building simplicidade.org: notes, projects, and occasional rants
email github facebook twitter flickr vimeo

git email workflow

I personally was never on the receiving end of a email-based git workflow so I don't know how hard it is to use git to track all the incoming patches and the status of each one.

I much prefer the workflow based around pull-requests, and the GitHub interface for them is extremely nice. Today, as I stood in the shower (it was a shower day, yes, and my best ideas usually hit me under running water) I started to think about a Web interface to manage email-based workflow's. This is a brain dump. I've tried to make it consistent, but I'm not sure I've succeeded.

I'll use GitHub as a target of this feature set, although I don't know how well it would integrate with their view of the world. The fact is that this system could be implemented with a local tool with a web interface and a POP3 client just for personal management of patch queues.

GitHub would provide one or mode email addresses associated with each project. These email addresses are basically treated as patch queues.

Collaborators would send patches by email (using the git-send-email command) to one of the queues. The system would track each patch individually having a state (new, under discussion, rejected, accepted, integrated, for example), and a discussion thread using the same comment system that commits have today. Each patch would be given a patch ID, basically the URL of the patch in this system.

Authenticated users could also add Signed-off-by: headers to each patch.

Patch authors could resend patch sets or individual patches. They could also include a Replace-Patch: header that would automatically link the two patches in the same discussion.

The queue administrator can also group patches into sets, both with the help of the patches Subject lines, or in a ad-hoc manner.

Each patch and each set has an HTTP URL that would return a mailbox formated to pipe directly into git-am. Only accepted patches should be included in the generated mailbox. Optionally, a Patch-Id: header could be added for future tracking.

Applying the a patch or patch set would be as simple as

wget URL-of-patch-or-patch-set -o temp.mailbox
git-am temp.mailbox

If this takes off, we could even patch git-am to accept URLs...

Alternatively, we could write a porcelain tool that would do:

  • record the HEAD ref;
  • fetch the mailbox URL;
  • call git-am with the mailbox file;
  • scan the log since the recorded ref. For all applied patches, signal GitHub that the patch was integrated.

The system could also use GPG to streamline some workflow's. For example, given a GPG white-list or a "trusted" signature (this one is more complicated because you would need to have the private key at GitHub), we could limit queues only to GPG-signed patches, or auto-accept them on the general submission queue.

Anyway, this is a brain dump. I don't use the mail workflow so I don't know how important this would be. I like this idea a lot.