This might work for slow moving teams with a few contributors, but I can't imagine using this in the way I've seen github used on projects with many contributors... Email just doesn't scale as well
> Using email for git scales extremely well. The canonical project, of course, is the Linux kernel. A change is made to the Linux kernel an average of 7 times per hour, constantly.
Tell that to any big team in a big company or even a medium-sized company using a monorepo. The Linux project has a very high bar for entry and it's not an example of a busy repo.
Linux upstream gets 7 commits per hour, but the Linux project is divided into subsystems which are run like independent projects that periodically push their work upstream. The volume of activity that Linux receives is very high.
Can you back up your statements with evidence? I have no reason to believe that email wouldn't work in a large monorepo-like setting. The less-than-10-in-total companies which have crazy Google-tier monorepos may run into issues with this (honestly, though, I doubt it), but they are not the norm.
Having to sort through messages individually, not being able to browse code, no convenient links, no formatting, no branch visualizations, release notes being easily accessible, having to set up a bunch of fragile text based filters. It's just obviously a worse choice
> having to set up a bunch of fragile text based filters.
Why?
I see arguments like yours about email and git a lot. Why do you think people disagree with you? You have to pay attention to what you are really saying. You are not listing advantages of web-based git interfaces. You are listing "disadvantages" of existing tools. And all of the "disadvantages" you list are really areas where you do not understand how to use Unix programming tools effectively. Getting off of webmail and onto a good text-based email client is one of the best things you can do as a computer user.
Or rather --- the age of text-based email clients has really come and gone. The world has moved on. Web or GUI based PRs are accessible to all developers of many different levels and experiences, that is why they have (and will continue to) be the winners.
Once again, an opinion from someone who does not know how to use the tools effectively. The world has moved on, and left web-based email clients behind. If you haven't checked out what modern text-based email clients and IMAP syncing tools can do, you are really missing out. I switched from Gnus to Gmail in 2006, and switched from Gmail to mu4e/offlineimap last year. The comparison is not even close; mu4e/offlineimap is an overwhelmingly superior solution.
Negative. An opinion from someone who finds the value in GUIs despite knowing about the alternatives. Use what makes you productive, but for MOST people, that is going to be a well done GUI over a text based solution. For me, I don't want to spend time configuring or fixing my email solution, I just want to login, get/read/reply to my email, and move on to real work. Don't confuse your opinion with what is "best" or "most effective" for most people, even developers and those ultra-familiar with the terminal.
I don't think the intent is to do code review from email. The idea would be to send the merge request through email, which is then imported into your local git as a branch. Then you're able to do review/analysis/etc with whichever git tooling you prefer.
You can still use a bug tracker with an email-based workflow. Many GNU projects use debbugs.gnu.org, which helps to keep track of patches that have been sent to the mailing list.
I can see how it would be inconvenient for people who use an inflexible email client or editor, though. (I'm trying to make this workflow a little less intimidating for Guix by working on a more convenient web interface on top of debbugs.)
I guess the question would be, what compelling reason would there be to do so? To me, the article's advantages are kinda meh, and I much prefer the tools provided in code review packages.
You may be right, but this comment breaks the site guidelines by being uncivil and unsubstantive. That's not a good way to be right on HN. Better is to politely provide necessary corrective information, so then the rest of us can learn something.