Sourcehut uses it, it’s actually the only way to interact with repos hosted on it.
It definitely feels outdated, yet it’s also how git is designed to work well with. Like git makes it really easy to re-write commit history, while also warning you not to force push re-written history to a public repo (Like e.g. a PR), that’s because none of that is an issue with the email workflow, where each email is always an entirely isolated new commit.
Compared to e.g. pushing a button in VS code and having your browser pop up with a pre-filled in github PR page? It’s clunky, but that doesn’t mean it’s not useful.
For starters it’s entirely decentralised, a single email address is all you need to commit to anything, regardless of where and how it’s hosted. There was actually an article on lobsters recently that I thought was quite neat, how the combination of a patch-based workflow and email allows for entirely offline development, something that’s simply not possible with things like github or codeberg.
The fact that you can “send” an email without actually sending it means you can queue the patch submissions up offline and then send them whenever you’re ready, along with downloading the replies.
Yeah it’s mad. Tbh I don’t think GitHub PRs are the best workflow, but I absolutely know that git send-email is the worst. I tried to use it once to contribute to OpenSBI, which inexplicably also insists on it. Suffice it to say my patch was never merged…
They wanted me to make some changes and with the normal workflow that’s just git commit and git push. With git send-email I have no fucking idea and it got beyond the point where I had enough cared enough to fight the process.
I would have thought that you fix it locally, git commit, and regenerate the patch set again. Maybe with optional squashing of commits so each patch set doesn’t keep growing.
Oh I see! Thanks. I thought that they deliberately rejected your patch. But it was more about the red tape getting in the way. Yeah, that sounds frustrating.
… if you have a super janky patch file workflow.
If you are using Git like normal people do this can’t happen.
The Linux kernel development workflow, the purpose for which git was invented, makes use of emailed patches https://docs.kernel.org/process/submitting-patches.html
I haven’t heard of any projects but Linux and Git itself using this.
Sourcehut uses it, it’s actually the only way to interact with repos hosted on it.
It definitely feels outdated, yet it’s also how git is designed to work well with. Like git makes it really easy to re-write commit history, while also warning you not to force push re-written history to a public repo (Like e.g. a PR), that’s because none of that is an issue with the email workflow, where each email is always an entirely isolated new commit.
I haven’t heard of anyone using Soucehut. (I guess Soucehut itself counts though.)
What, why?
Compared to e.g. pushing a button in VS code and having your browser pop up with a pre-filled in github PR page? It’s clunky, but that doesn’t mean it’s not useful.
For starters it’s entirely decentralised, a single email address is all you need to commit to anything, regardless of where and how it’s hosted. There was actually an article on lobsters recently that I thought was quite neat, how the combination of a patch-based workflow and email allows for entirely offline development, something that’s simply not possible with things like github or codeberg.
https://ploum.net/2026-01-31-offline-git-send-email.html
The fact that you can “send” an email without actually sending it means you can queue the patch submissions up offline and then send them whenever you’re ready, along with downloading the replies.
Ah, the process you mean. patch itself is still useful.
deleted by creator
… which arguably makes them not “normal people” (referring to the earlier comment).
Surely, most people use different, more integrated tooling.
Yeah it’s mad. Tbh I don’t think GitHub PRs are the best workflow, but I absolutely know that
git send-emailis the worst. I tried to use it once to contribute to OpenSBI, which inexplicably also insists on it. Suffice it to say my patch was never merged…Why didn’t your patch get merged?
They wanted me to make some changes and with the normal workflow that’s just
git commitandgit push. Withgit send-emailI have no fucking idea and it got beyond the point where I had enough cared enough to fight the process.I would have thought that you fix it locally, git commit, and regenerate the patch set again. Maybe with optional squashing of commits so each patch set doesn’t keep growing.
Oh I see! Thanks. I thought that they deliberately rejected your patch. But it was more about the red tape getting in the way. Yeah, that sounds frustrating.