4 ms·

PRs are decentralised. Everyone has their own "fork" of the repo, makes changes there, then tries to convince the maintainer of the "main" repo to pull. This i

PRs are decentralised. Everyone has their own "fork" of the repo, makes changes there, then tries to convince the maintainer of the "main" repo to pull. This is exactly what the decentralised model was meant to do. It doesn't mean that every copy of the repo is equal in importance, but they are equal in functionality. (Or, maybe you mean that it's "centralised" in the sense that it's all on github.com?)

palata 3y ago
Well the git repo is decentralized (everyone has a copy of it). PRs are not. All the PRs are living on one centralized server (usually github.com), such that if that server is down, nobody has access to the PR. When you send your patch to a mailing list (with `git send-email`), then that patch is immediately distributed to all the mail servers. This is decentralized: everyone gets a copy of your email (which is the equivalent of a PR in the email workflow). > Or, maybe you mean that it's "centralised" in the sense that it's all on github.com? That's the other thing: the PR workflow tends to naturally push towards a monopoly. It is annoying to have to create an account on every GitLab instance under the sun just to send a PR. More and more, if your project is not on GitHub, people will not bother to create an account for you. With the email workflow, you don't need an account: you just send your email to the mailing list (you don't even have to subscribe to the mailing list) or to whoever you want to send it. This makes it much easier to deal with different servers (contributing to 100 projects on 100 different servers does not makes you create 100 accounts).
- colonwqbang 3y ago
  I see your point. Do you think some kind of federation could help here? If there were 10-100 different github-like servers all set up to "git pull" from each other, would that make it a decentralised system to you? Even email is not fully decentralised anymore since we need to use a proxy to send email nowadays.
  - palata 3y ago
    I read that Gitlab is working on some kind of federation of instances, where one could fork a repo from instanceA into instanceB and open a PR from instanceB to instanceA (instead of having to create an account on instanceA and fork the repo there). I guess it would be good if it helped against this "lock-in" effect that pushes everybody to GitHub. Though I doubt GitHub would ever federate (obviously) and another lock-in factor is that people are used to the GitHub tooling and may be reluctant to use a different WebUI just for a few projects. But that all sort of feels overly complicated to me, to be honest. Because the email workflow already solves that in a minimal way. I can send patches to any email address I want without creating an account, and I can use my favourite tools everywhere without even needing a browser. I like minimalistic solutions :-).

palata 3y ago

Well the git repo is decentralized (everyone has a copy of it). PRs are not. All the PRs are living on one centralized server (usually github.com), such that if that server is down, nobody has access to the PR. When you send your patch to a mailing list (with `git send-email`), then that patch is immediately distributed to all the mail servers. This is decentralized: everyone gets a copy of your email (which is the equivalent of a PR in the email workflow). > Or, maybe you mean that it's "centralised" in the sense that it's all on github.com? That's the other thing: the PR workflow tends to naturally push towards a monopoly. It is annoying to have to create an account on every GitLab instance under the sun just to send a PR. More and more, if your project is not on GitHub, people will not bother to create an account for you. With the email workflow, you don't need an account: you just send your email to the mailing list (you don't even have to subscribe to the mailing list) or to whoever you want to send it. This makes it much easier to deal with different servers (contributing to 100 projects on 100 different servers does not makes you create 100 accounts).

colonwqbang 3y ago
I see your point. Do you think some kind of federation could help here? If there were 10-100 different github-like servers all set up to "git pull" from each other, would that make it a decentralised system to you? Even email is not fully decentralised anymore since we need to use a proxy to send email nowadays.
- palata 3y ago
  I read that Gitlab is working on some kind of federation of instances, where one could fork a repo from instanceA into instanceB and open a PR from instanceB to instanceA (instead of having to create an account on instanceA and fork the repo there). I guess it would be good if it helped against this "lock-in" effect that pushes everybody to GitHub. Though I doubt GitHub would ever federate (obviously) and another lock-in factor is that people are used to the GitHub tooling and may be reluctant to use a different WebUI just for a few projects. But that all sort of feels overly complicated to me, to be honest. Because the email workflow already solves that in a minimal way. I can send patches to any email address I want without creating an account, and I can use my favourite tools everywhere without even needing a browser. I like minimalistic solutions :-).