> Isn't this perhaps the greatest validation of Linus's design genius that what was initially a weekend project has successfully scaled to this?

I thought the entire point of the article was to show how git didn't scale, and how they're basically rewriting the project and changing it as much as necessary to make it scale. It's not like Linus designed git to scale as O(modified).

On the other hand, becoming something bigger out of his hands is validation in it's own right...

And Linux was a hobby project as well... now it runs most of the internet AND most of the personal computing devices on the planet.

No, not really. When it scaled enough for the Linux kernel he lost interest in scaling any further, and that's nowhere near what's needed for a monorepo (or a Linux distribution).

And I recall that there are was fairly infamous tech talk at Google where he basically dismissed Google's concerns in an arrogant way.

So I'd say it's mostly a validation of git and Github's popularity with developers, that other people were willing to put in so much work to improve it.

Well by "validating git" aren't you by proxy validating its design by its creator?

Or am I missing something key here? Yes of course it's been extended by very smart people has new features etc etc...but a weekend project that was robust enough to handle the Linux kernel codebase for him? That's is no small feat.

Oh yes perhaps its the new meme among developers that there are no real genius architects and coders and that anyone could have done it really so why distribute props to any one creator?

Yeah given my experience I have a hard time buying into that mindset.

Sure, that weekend project was extremely successful, and git has a pretty clean design.

My point is that it didn't scale to monorepo size, and was never intended to do anything like that. (How many years did it take before Microsoft came along and decided to do it?) Making a claim like that is basically hero worship.

When software is popular enough, people will jump through all sorts of hoops to extend it and maintain compatibility with it. (For example, POSIX, JavaScript, Java, or even PHP.) These technologies all have their good parts and bad parts. The quality of the design is less important than whether it fulfilled a need successfully and appeared at the right time.