Git Over Email?

Convienence over Coolness

I keep looking at “Source Hut” (née “srht”) and its email-centric approach to git. It kind of appealed to me in the sort of theoretical, slightly-masochistic way that switching to BSD or terminal-only mode has in the past – something that is idealized as being simpler, more efficient, allowing one to use the honed tools of true hackers, or whatever.

However, after going through the tutorial thoughtfully provided by sourcehut on how to collaborate over email with git and reading some of the resultant discussion, I was reminded why most people & projects don’t collaborate in that way. Not only is it a non-trivial hassle to set up git to send email (including having to find some reasonably-secure way of storing an email password), but it really seems to end up being a lot less convienent to actually use: You are discouraged from using your usual email client and told to only send via git send-email; however, you still need to go to whatever mailing list the patch is being discussed on with some sort of client, because you need to get the message id to send follow-up patches to; multiple commits send as multiple separate emails, which seems incredibly annoying; there’s now no one place you can look to see all the in-process changes and their status; it seems to more-or-less require constantly ammending & changing commit history, seems like losing information for no good reason.

Personally, it seems like it would be a massive pain to have to use my email to manage contributions for both sending & recieving to a variety of different projects. I’m not a huge fan of Github, but the pull-request flow is pretty easy to use. It’s easy to manage a bunch of contributions, comment line-by-line on the changes, see the history of the changes, and generally make the discussion easy to follow & find. Even if one doesn’t want to use the website, using a tool like magit one can use the API for the git hosting service and see the commits & discussion without leaving the editor, as well as configure things so one can directly check out a branch corresponding to the PR (so you can pull from there too, without having to mess around with repeatedly applying and discarding patches).

I don’t want to cast aspersions on the people championing these ways of using git – philosophically, I can get behind the idea of using git in a more federated way – but it does seem to me to be kind of the sort of thing that I wrote about previously, where people don’t want to use interfaces which are far more ergonomic precisely because they are more ergonomic, as that user-friendlyness is looked down upon.

I am well aware there are big projects that do use an email-centric workflow. However, I think it is not a coincidence that those are also projects that are not particularly renowned for being easy to contribute to.

I teach at a learn-to-code bootcamp and, while learning to use all the tools is always a challenge for the students, using graphical interfaces like github and the pull request systems is something they usually are able to figure out themselves – just the discoverability of having buttons show you what your options are is way less intimidating to beginners. If they had to figure out how to configure git send-email, getting patch files from those emails, and then how to apply them, I am quite sure their rate of success would be far lower.

Being easier isn’t only to help beginners get started though. Experts too can benefit from not having to expend mental energy on remembering exactly the sequence of commands required for complex operations. I consider myself pretty proficient at using git from the terminal, but I prefer using magit because it’s simply easier – my goal is to write code, not use git. I’ve contributed tiny changes to projects on Github that I never would have if a more heavyweight flow was required, because it’s almost as easy as editing a Wikipedia article – the way I can click “edit”, have an in-browser editor to make a small change, and submit a PR without having to go to the terminal once is great.

I do wish that there was a way to have something like Github’s pull-request system without being tied to their proprietary system. Clearly though, for things requiring people to communicate, different projects will have different needs. It would be interesting to see something like Fossil’s system, where the issues, wiki, etc are all part of the repository itself, so a pull-request-like concept could be a native aspect of the system. For now though, I don’t think I’m going to be switching to an email-based workflow – it really seems like just adding complications for nebulous benefits – and I’m going to keep hoping that we can make our tools more accessible, not more exclusive.