6 ms·

Grain of salt: I've become a curmudgeon w.r.t software complexity over the last decade, but git is already distributed. What's wrong with patch email chains? Or

Grain of salt: I've become a curmudgeon w.r.t software complexity over the last decade, but git is already distributed. What's wrong with patch email chains? Or the current existing wrappers around git that allows for distributed review chains (i.e. git(hub|lab), etc.)?

gouggoug 3y ago
> What's wrong with patch email chains? 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.
goku12 3y ago
> What's wrong with patch email chains? 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.
- palata 3y ago
  > Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal. 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: https://aerc-mail.org/ https://aerc-mail.org/ > 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.
  - goku12 3y ago
    > I agree that e-mail is not perfect, but... how is GitHub better? 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/ 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.
    - palata 3y ago
      > We really should have something better than 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...
palata 3y ago
> Grain of salt: I've become a curmudgeon w.r.t software complexity over the last decade 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.
qudat 3y ago
I love the idea of using email to send patches, but the UX is not well suited for the business requirements. 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.

gouggoug 3y ago

> What's wrong with patch email chains? 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.

goku12 3y ago

> What's wrong with patch email chains? 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.

palata 3y ago
> Another problem is how badly email threading is displayed in these clients. Email UI is still abysmal. 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: https://aerc-mail.org/ https://aerc-mail.org/ > 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.
- goku12 3y ago
  > I agree that e-mail is not perfect, but... how is GitHub better? 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/ 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.
  - palata 3y ago
    > We really should have something better than 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...

palata 3y ago

> Grain of salt: I've become a curmudgeon w.r.t software complexity over the last decade 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.

qudat 3y ago

I love the idea of using email to send patches, but the UX is not well suited for the business requirements. 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.