[xprn]

I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror).

There might very well be some context I’m missing, but that’s what I understand from that side at least.

[fragmede]

they (well, Linus) invented git for their purposes, and not the other way around. They use git and mailing lists because that's how they work, and that's how they worked before git existed. git was built for them.

[jorvi]

Github / Gitlab would work great and reduce friction for kernel contribution. The refusal to switch or provide the alternate path is mostly inertia.

[zer00eyz]

I think you have a story eyed view of github... You might want to go read Linus own thoughts on the matter in the linux GitHub backup repo

Git is a tool built for a project of the kernels scope, scale and organization.

Github is a thin web interface over top of that, it cuts some corners here and there and gets opinionated about how you should manage code (pull requests).

Think of it this way: most git hub projects end up with a monotonic output... the kernel isnt that. Between the current version someone is using, the next version that is being developed and the older versions getting back ports there's a lot going on there. Much more than GitHub and a pull request would cover.

[skydhash]

Sometimes friction is necessary for quality. More often than not, I’ve seen github repos where issue is treated as a project manager and there are lots of drive-by PRs.

[mhh__]

Github and gitlab are both deeply, fundamentally, flawed because the unit of contribution is the branch rather than the commit.

Other than the UI not being very good, the code review experience is fundamentally hampered unless you enable squashing but that's a bit shit for different reasons.

On a purely UX level too the velocity of getting patches in is terrible. They're designed for ad-hoc open source contribution, not tight-loops of consistent work. People put up with the slowness because they know no difference but I promise its slow. You shouldn't need to go and get a coffee to wait for something to get merged and start coding again.