It's amazing how git is a distributed system, but everybody chooses to use it in a centralized manner with PRs (mostly on GitHub).
BTW GitHub is having issues today.
BTW GitHub is having issues today.
Linux development is the most public example of this, here's an example from today:
https://lore.kernel.org/linux-block/20240109071332.2216253-1...
I would be really curious to have your opinion about it as compared to how it was 14 years ago. I feel like SourceHut does a really good job helping on the tooling side (it's super easy to setup a mailing list).
Also I find Aerc very cool for that. The author describes it here: https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
Unfortunately, all my projects require tools that claim to be past "alpha" status, so I can't consider it yet.
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?)
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).
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 :-).
I meant more in terms of development. The way git is used most of the time is by having a main branch on GitHub, that contributors clone, work on a feature branch, then make a PR, have QA test it, and merge it. If that cycle is too slow, many times the devs will start complaining because they are "stuck until the branch is merged". Because the assumption is that everybody branches from the main branch.
But git was designed around the email workflow. Instead of a PR, you make a patch (or a group of patches), that you can share with others. For instance, you can share a patch with a colleague from your team, who will review it and incorporate it in their branch before it gets merged into main. That way they are testing it by using it. At some point your changes get merged into the main branch, and your coworkers can just apply their patches on top of it.
We can imagine a workflow with a hierarchy of maintainers: devs at the lower level send patches to their supervisor, who after a while sends them up to their supervisor, up to the main branch.
PRs flatten all that. Devs typically never learn how to deal with patches, and the review process ends up being "rebase on main, run the CI, then I'll skim through your code, I'll complain about some variable names and I'll approve without even pulling your code" (I'm exaggerating a bit, of course).
I think there is a lot of value in learning the git email workflow.
This post (not mine) is about this: https://web.archive.org/web/20170823054920/https://dpc.pw/bl...
And of course SourceHut (https://sourcehut.org/, not mine) is a great forge built around the email workflow.
That my VCS is distributed is a goes-without-saying at this point. Nothing else is good enough. But a completely different dimension is integration. And I want to be as integrated as possible. And for everyone else as well. I don’t want three different cliques working on disparate things. And I warn against such things at work as well (i.e., hey let’s make a branch for this project which 3/9 of us is going to work on for a month...).
> But git was designed around the email workflow. Instead of a PR, you make a patch (or a group of patches), that you can share with others. For instance, you can share a patch with a colleague from your team, who will review it and incorporate it in their branch before it gets merged into main. That way they are testing it by using it. At some point your changes get merged into the main branch, and your coworkers can just apply their patches on top of it.
This certainly has merit. I mean peer-to-peer integration branching. But you can do the same with forges and branches. In fact it’s more difficult to keep track of patches via email, i.e. what comes from where, have I included this already, etc. Just consider the conversations that seem to keep coming up on how to deal with identifying patches.[1]
> We can imagine a workflow with a hierarchy of maintainers: devs at the lower level send patches to their supervisor, who after a while sends them up to their supervisor, up to the main branch.
I mean you should expect Whatever The Law about the org hierarchy being reflected in processes, not vice versa. Apparently there isn’t a process for this command hierarchy to be reflected in.
> PRs flatten all that. Devs typically never learn how to deal with patches, and the review process ends up being "rebase on main, run the CI, then I'll skim through your code, I'll complain about some variable names and I'll approve without even pulling your code" (I'm exaggerating a bit, of course).
Patches or not doesn’t really change that. If one single email thread becomes the focal point of a month-long development “PR” then that’s the same thing.
But yes. Getting out of that dang “fork” mindset is good. You can be more loosey goosey via email since you just inline your suggestions as patches (either with a commit message or without).
[1] https://lore.kernel.org/git/bdbe9b7c1123f70c0b4325d778af1df8...
In his use case, he is the single source of truth who decides what gets merged.
If you're simply using the software, you would pull the maintainer or whoever is hosting the main branch or what have you.
Ipfs remote for git should be the default.
If I wanted to use git on ipfs, I could host a node and push all my git commits there, but I’d have to convince others to host it as well, correct? So perhaps it would be awesome for majorly popular projects, but still a end up having a SPOF for smaller projects right?
GitHub and the PR workflow tend to make it all centralized.
Not sure I get that. You do `git send-email --to=<mailing-list-address>` and that's it. Everyone on the mailing list gets a copy of your patch, that they can apply if they want.
So if everything on the entirety of github.com was deleted, you could still do a git clone somehow and it would pull it from everyone who has ever cloned that repo?
Because that's what I'm referring to here - p2p not hub-spoke architectures.
I'm fairly certain git doesn't inherently have this feature, unless the backend remote could automatically start an iOS or torrent daemon and deal with torrent or ipfs for pulling and pushing.
I think you are talking about distributing the git server itself over p2p. Which I find less important because I don't think that the server bandwidth is usually a problem. Or is it?