Nothing (aside from the lack of UX/UI, but some might see this as a plus)
> Or the current existing wrappers around git that allows for distributed review chains (i.e. git(hub|lab), etc.)?
They are centralized. I must have access to github.com to do my review and when git(hub|lab|random-pet-project).com disappears, so do all the PR reviews.
The fact that it's email. There are two categories of problems with it:
1. It's been extended unnecessarily and implemented poorly. The biggest one in this category is HTML email. It's really hard to write mails using common clients without messing up mailing lists. Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal.
2. Many features of emails are an afterthought. Email obviously arose when E2EE, privacy features, attachments and spam prevention were not big concerns. When they got eventually added, they added too many moving parts, complexity and lack of enforcement. I wish there was a modern successor to emails (immutable federated messaging) with less components, standard and mandatory E2EE and signing, built-in list support and spam management features.
None of this is to say that git did it wrong. Even with all these problems, I still prefer the freedom offered by email to being tied-in to specific platforms.
Fair point. However, given that the current alternative is "use another service entirely (e.g. GitHub)", I think it would be fair to assume that devs could choose a good e-mail client and learn how to format such e-mails correctly. It works for Linux, for instance. I started using Aerc, and I love it:
> Many features of emails are an afterthought.
I agree that e-mail is not perfect, but... how is GitHub better? With e-mail, you can send your patch encrypted (e.g. with PGP) if you feel the need, but otherwise it will go over HTTPS (same as GitHub). I honestly don't really know about attachments (I guess you would encrypt them with PGP as well?), but again, attachments on GitHub are not E2EE...
I tend to believe that people use GitHub for different reasons, for instance:
1. It is the first thing they see when they join the industry
2. Cargo-cult, a little bit
3. Devs like new shiny toys, and e-mails are old technology ("we should have something better than e-mail in 2023", which I disagree with).
4. Nobody takes the time to try the e-mail workflow (even though it's really two git commands). Actually it is common to not really take the time to learn the basic tools, I feel.
Please look at my comment again. I prefer email to locked in forges.
> Devs like new shiny toys, and e-mails are old technology
There is one aspect where such forges have an advantage over email - a better user experience. Aerc and the likes all good - but Github and others provide a good user experience over a tool that everyone uses - the web browser.
> we should have something better than e-mail in 2023
We really should have something better than email. I'm saying this as someone who operates a personal mail server and a bunch of desktop services for it. It's really hard to get the setup correct.
In that context, it's worth looking at forgefed (https://forgefed.org/). It's a protocol for federating forges like Gitea and Gitlab. It's built on top of ActivityPub - which behaves a bit like email (it has inboxes and outboxes for every user). From the spec, it seems like pull requests happen by sending patches to the destination forge.
> Nobody takes the time to try the e-mail workflow (even though it's really two git commands)
Email workflow seems simple. But there are two things that make it complicated:
1. The patches don't specify the commits they apply to. It's simply assumed that they apply to the head of the main branch. The commits have to be carefully rebased on the main branch before sending the patches. It could otherwise lead to conflicts and a lot of wasted time.
2. Each commit/patch is send as a single email. Developers usually make frequent commits when they develop. Such patches can be confusing and hellish to review. A sane patchset requires the developers to edit the commit history, usually using interactive rebases. Each commit should contain a single feature and shouldn't break the build.
I consider both the above to be good development practices and follow them even on my personal projects. However, this is an additional barrier to entry. In fact, this may be a bigger problem for many than setting up git for email.
Maybe, but e-mail is here, the whole world knows and uses it, and even if it is not perfect, I think it does the job pretty well (put aside the fact that managing a server is hard).
> However, this is an additional barrier to entry.
Agreed. I just feel like we keep pushing the barrier down, but at some point, professionals need to learn the basics. I don't feel like we need more software in our world. We need better software. And if people can't learn their tools, I don't know if we can seriously expect them to write good software...
Last time I suggested [1] an approach to learning and taming the git CLI, somebody said that they want to design and write code, rather than learn too much CLI-fu. Big projects like Linux and Emacs can get away with requiring their contributors to learn the tools well enough. However, many developers may decide to avoid contributing rather than learn the tool, if the project is a small one.
Again, I agree with what you say - that's what I practice too.
Think about a junior joining a company. Through the first weeks they get: to be useful you need to learn about dependency management, git, frameworks we use, data stores we use, processes for review, our ci approach, our release approach, ...
Adding yet another process your work depends on, is fiddly to setup and doesn't have good docs online really isn't great. "We can add this on top, it's just basics" can really add up with enough systems.
That's the thing. In my view, you say "we should keep adding wrappers on top of wrappers and libraries on top of libraries, such that juniors can quickly get productive, but nobody actually understands what they are doing anymore and the smallest executable takes 50MB".
I say "we should reduce the number of dependencies such that one can understand the system better, even if it means that juniors need to spend time learning the basics".
Of course there is a balance to find (not everybody needs to master assembly), but the modern way, IMHO, goes too much towards productivity, and not enough towards mastering ones tools.
For me, being able to edit the patch request without spamming everyone on the email list would be nice. Making changes to the patch request requires convention to link them together.
The patch requests are completely decoupled from the git repository so now you need something else to generate the mailing list.
When comparing a PR tab in GH to mailing list patch requests, it should be obvious which one is better at reading/searching/linking previous patches.
Same here :-). I have come to think that old and simple technology was nice, and the trend nowadays is to pile up a lot of complexity for no apparent reason.
> What's wrong with patch email chains?
I genuinely believe that most developers (who I believe have less than 5 years experience) have never seen the e-mail workflow in their life. And there is a tendency to believe that newer is better, so they don't even consider e-mail.