That said, a workflow based on Github (or similar) has the advantage of first-class CI, cleaner reviews, and other intricate project settings (like teams, etc.). I’m glad my own projects are on Github.
And inferior quality patches and careless code review.
Github does quite a bit of work to hide patches and commit messages. As a result, individual commits and their messages tend to be rather bad. The emphasis is to instead review the entire diff of the whole PR as a whole.
When you email a patch, the patch itself, the commit, that’s what becomes the object of discussion. Your commit message is then an email message designed to convince mailing list readers why the change should be accepted.
The end result is a much cleaner history where each commit embodies the result of a discussion and each message summarises the argument that promoted that diff into a commit.
Here is final form of the code, after being nudged in various directions by maintainers:
And that’s what mailing list discussion does.
The easy “merge” button you click on github instead discourages this sort of discussion.
I think it has less to do with the tools and more with the people involved in the project. I can create messy commits with patch files and super nice commits with github (or other forges). It depends on how you use the tools.
You also completely ignore the CI aspect, which I believe is just as important and a lot harder to do in a lose mailing list development style.
I think the truth is that there are few mailing list based projects because it is essentially gatekeeping and very hard to get into. I can write perfectly fine quality software without ever having to worry about email quoting or html vs. plain text and whatever else comlex requirements there are because the software devs are stuck in the 90ies. Email is not a good tool to develop software and I think everyone who believes otherwise has essentially a mild form of Stockholm syndrom. The whole “rite of passge” thing comes to mind too. There are better ways.
There are infinitely more projects on github than ones that use mailing lists, so of course you will find sloppy ones. But the tools that github (or other forges) give you, allow you to do a lot more (CI, package registry etc.), have a low barrier of entry and are user friendly.
I think the truth is that there are few mailing list based projects because it is essentially gatekeeping and very hard to get into
And the truth is that github PRs tend to produce unreadable history because nobody wants to write history, they just want to write code. If you want to fling accusations of Stockholm syndrome without understanding what is good about email-based workflows, I’ll do the same about Github: they convinced everyone to do superficial and ultimately useless code review, and everyone who likes Github has some mental problem, just like you accused us who like email.
Or if we agree that history and commit messages are not worth writing, like the Github UI encourages you to think of, then we need a better tool that isn’t centred on writing commit messages and patches. We need something better than git.
And the truth is that github PRs tend to produce unreadable history because nobody wants to write history, they just want to write code.
Github has pull request templates that one can enforce on a project. Nothing stops anyone from using those. I fail to understand how an email based flow, where I have to rely on someone with commit/push rights to get my patch in makes this better. The fact that this is using email does literally nothing to enforce that.
I’ll do the same about Github: they convinced everyone to do superficial and ultimately useless code review, and everyone who likes Github has some mental problem, just like you accused us who like email.
I think the major contribution of GH is that code reviews are now the norm and not an exceptional thing that people do. It also has made it infinitely easier for people to contribute to a project. You keep on ignoring how high the barrier for email based flows is.
PR templates on Github are not commit templates. My complaint with Github is that people write unreadable individual commits which produces useless history. Commit messages like “addressing issues from code review” and commits themselves like these are useless, because the only way to know what happened with such a project is to check associated PRs. Github tries to make commits useless and only focusses on PRs. You can’t just read the git history because Github tends to produce useless history. It makes tools like git blame very hard to use.
And like I said, either tool can do either thing. You can have CI with email workflows. You can write clean commits with github. What email encourages, though, Github discourages, and vice versa.
You think we like email just because we’re old, crotchety elitist assholes who can’t get with the times, but no: we like email because it produces a VCS history that you can refer to later to know why the code is the way it is. It’ll tell you what the person was thinking about, in detail, for each line written. With a good history git blame becomes source-level documentation for each line of code in your codebase.
You also completely ignore the CI aspect, which I believe is just as important and a lot harder to do in a lose mailing list development style.
When we receive a PR for some of the projects that I work on on GitHub, CI tells us:
Does it match the style as enforced by clang-format?
Does it fail to build on any of our supported platforms?
Does it introduce any test regressions on any of the supported platforms?
Do the new tests that it adds introduce any failures?
This means I don’t need to care about formatting-related bits of the review and I don’t need to care about functional correctness for anything that’s tested. I can focus on things like:
Does it pick sensible algorithms / data structures that will scale the way we want?
What are the corner cases that the tests don’t cover? If they’re easy to test, can we add a test for them? If they’re not, I need to carefully review the code paths that they’d hit.
Does it introduce new APIs that don’t fit with the rest of the project / would be difficult to support long-term?
Does it duplicate any code that should be factored out?
These are the things that you really need a human for and they’re the things that I can focus on with GitHub-style PRs. With mailing-list ones, unless you’ve managed to automate things based on email triggers, people generally have to cover a lot of the related things.
Also surprised they used git diff instead of git format-patch, and also surprised that they didn’t use git send-email. I wonder if this is just “how I happened to submit patches to Emacs” rather than “the recommended way to submit patches to Emacs”.
And inferior quality patches and careless code review.
Github does quite a bit of work to hide patches and commit messages. As a result, individual commits and their messages tend to be rather bad. The emphasis is to instead review the entire diff of the whole PR as a whole.
When you email a patch, the patch itself, the commit, that’s what becomes the object of discussion. Your commit message is then an email message designed to convince mailing list readers why the change should be accepted.
The end result is a much cleaner history where each commit embodies the result of a discussion and each message summarises the argument that promoted that diff into a commit.
And that’s what mailing list discussion does.
The easy “merge” button you click on github instead discourages this sort of discussion.
I think it has less to do with the tools and more with the people involved in the project. I can create messy commits with patch files and super nice commits with github (or other forges). It depends on how you use the tools.
You also completely ignore the CI aspect, which I believe is just as important and a lot harder to do in a lose mailing list development style.
The tools can be used to do either thing, but the tools encourage a particular direction.
I think the truth is that there are few mailing list based projects because it is essentially gatekeeping and very hard to get into. I can write perfectly fine quality software without ever having to worry about email quoting or html vs. plain text and whatever else comlex requirements there are because the software devs are stuck in the 90ies. Email is not a good tool to develop software and I think everyone who believes otherwise has essentially a mild form of Stockholm syndrom. The whole “rite of passge” thing comes to mind too. There are better ways.
There are infinitely more projects on github than ones that use mailing lists, so of course you will find sloppy ones. But the tools that github (or other forges) give you, allow you to do a lot more (CI, package registry etc.), have a low barrier of entry and are user friendly.
And the truth is that github PRs tend to produce unreadable history because nobody wants to write history, they just want to write code. If you want to fling accusations of Stockholm syndrome without understanding what is good about email-based workflows, I’ll do the same about Github: they convinced everyone to do superficial and ultimately useless code review, and everyone who likes Github has some mental problem, just like you accused us who like email.
Or if we agree that history and commit messages are not worth writing, like the Github UI encourages you to think of, then we need a better tool that isn’t centred on writing commit messages and patches. We need something better than git.
Github has pull request templates that one can enforce on a project. Nothing stops anyone from using those. I fail to understand how an email based flow, where I have to rely on someone with commit/push rights to get my patch in makes this better. The fact that this is using email does literally nothing to enforce that.
I think the major contribution of GH is that code reviews are now the norm and not an exceptional thing that people do. It also has made it infinitely easier for people to contribute to a project. You keep on ignoring how high the barrier for email based flows is.
PR templates on Github are not commit templates. My complaint with Github is that people write unreadable individual commits which produces useless history. Commit messages like “addressing issues from code review” and commits themselves like these are useless, because the only way to know what happened with such a project is to check associated PRs. Github tries to make commits useless and only focusses on PRs. You can’t just read the git history because Github tends to produce useless history. It makes tools like
git blamevery hard to use.And like I said, either tool can do either thing. You can have CI with email workflows. You can write clean commits with github. What email encourages, though, Github discourages, and vice versa.
You think we like email just because we’re old, crotchety elitist assholes who can’t get with the times, but no: we like email because it produces a VCS history that you can refer to later to know why the code is the way it is. It’ll tell you what the person was thinking about, in detail, for each line written. With a good history
git blamebecomes source-level documentation for each line of code in your codebase.When we receive a PR for some of the projects that I work on on GitHub, CI tells us:
This means I don’t need to care about formatting-related bits of the review and I don’t need to care about functional correctness for anything that’s tested. I can focus on things like:
These are the things that you really need a human for and they’re the things that I can focus on with GitHub-style PRs. With mailing-list ones, unless you’ve managed to automate things based on email triggers, people generally have to cover a lot of the related things.
You can have that with email too, Mercurial uses email-based development and there are buildbots running CI.
Sure, it’s not maintained by github, but there isn’t anything specifically anti-CI about email, other than being more of a pain to setup than github.
Sourcehut runs CI on mailing lists automatically, even.
Doesn’t github’s squash-and-merge option give the same behavior as described in the blog post with
git diff branch1 branch2?I’m surprised that the patch was added as an attachment. I always found that the best part of the email workflow was commenting on the latches inline.
Also surprised they used
git diffinstead ofgit format-patch, and also surprised that they didn’t usegit send-email. I wonder if this is just “how I happened to submit patches to Emacs” rather than “the recommended way to submit patches to Emacs”.I think this is because Emacs mail clients display text attachments inline anyway. The replies to patches make it seem like this might be the case:
https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00502.html
Good article. I wish it went into more detail on
git format-patchandgit am, however. Mailing patches around is fun and more people should do it.https://drewdevault.com/2018/07/02/Email-driven-git.html discusses more on the advantages of email-driven workflows.
https://git-send-email.io/ discusses how to do it on different platforms.
I like it and I like PR-style development too.
Did not know about elisp unit tests and (should), thanks!