> 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 br

> 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. 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/bdbe9b7c1123f70c0b4325d778af1df8fea2bb1b.camel@that.guru/ https://lore.kernel.org/git/bdbe9b7c1123f70c0b4325d778af1df8...