[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.

[jorvi]

Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. People see a bit of code they want to improve, they improve it, and then instead of just opening a PR (and perhaps iterating on it), now they have to learn a weird ancient e-mail workflow and will probably get chewed out for messing it up.

No one is saying to take away mail-in patches but it is positively archaic.

[zer00eyz]

>> Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution.

Is it friction? Or is it a filter?

You might remember being a kid and there was the sign in front of the ride that said "you must be at least this high to ride".... The kernel dev process isnt for casuals. It's designed that way.

There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests.

You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons).... Your going to look at git in a very different way and many of githubs features are gonna feel on par with linkedin adding twitch style videos and zoom adding mail features...

[jorvi]

> Is it friction? Or is it a filter?

Friction.

> There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests.

So be stringent. First below-par PR get some guidance, pointers and perhaps a reprimand. Second time, a warning, third time a ban.

> You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons)....

Code is code. If someone has an improvement, they can offer their new code.

I’m sure the kernel has a unique workflow, but it ultimately boils down to that, no?

[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.

[GuB-42]

A unit of contribution is always a branch, implicitly or explicitly. What you have in your local repository is a branch of what is in the central repository, which is a branch of what you have in your filesystem, which is a branch of what you have open in your editor. In the same way a contribution is always a merge, saving a file is merging the content of your editor in your filesystem, committing is merging your file in your local repository, and pushing is merging your local repository with the central repository.

That's git main insight, branching is everywhere, so it is designed with branching and merging as fundamental, explicit, and regular operations. Seeing how successful git is, it looks like it was a good choice.

GitHub and GitLab are built on top of git, and follow its principles, so that making the branch the unit of contribution is simply natural.

Of course, you can make single commit branches, in fact, that's what squashing is for. There is, of course, no obligation to wait before you have your change merged before you start working again, you can start from an earlier version and rebase later, merge back some changes, or do whatever you want really. You can tight-loop as much as you want, especially on your local machine.

[mhh__]

The way (say) the kernel uses branches is not very similar to the way GitHub does it where you actually push a branch and then let the machine do the merge

It's the same ingredients but it's very hamfisted.

Squashing is like training wheels.

What I was hinting at with the loop concept is that it should be closer to phabricator that gitlab, let me stack.