Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd rather see google open up their monorepo as a platform, and compete with github. git is fine, but there's something compelling about a monorepo. Whether they do it one-monorepo-per-account, or one-global-monorepo, or some mix of the two, would be interesting to see how it shapes up.


Though as things are going, I wouldn't be surprised if Amazon goes from zero to production-quality public monorepo faster than Google gets from here to public beta. It's not in Google's blood.

And of course Google will shut it down in five years once they're bored of it.


Amazon doesn't do mono-repos. They have ORDER OF a million repos. They instead invested in excellent cross repo meta-version and meta build capabilities instead of going mono-repo.


"one-global-monorepo" caused me to envision a beautiful/horrifying Borg-like future where all code in the universe was in a single place and worked together.


This is how Linux (and BSD, and so on) distributions work. Of course there are proprietary and niche outliers, but you can't forbid those in the first place.


I felt like that when I first saw golang and how you can effortlessly use any repo from anywhere.


As the joke goes, Go assumes all your code lives in one place controlled by a harmonious organization. Rust assumes your dependencies are trying to kill you. This says a lot about the people who came up with each one.


> Rust assumes your dependencies are trying to kill you.

Would you mind unpacking this? I'm intrigued.


Cargo.lock for applications freezes the entire dependency graph incl. checksums of everything, for example.


This is the main thing I miss about subversion. You could check out any arbitrary subdirectory of a repository. On two projects the leads and full stack people had the whole thing checked out, everybody else just had the one submodule they were responsible for. Worked fairly well.


Mercurial has narrowspecs these days too! Facebook's monorepo lets you check out parts of the overall tree too. It's not like every Android engineer's laptop has all of fbios in it.


Git has submodules too and teams usually have access control on the main server used for sharing commits.


git submodules aren't seemless. None of the alternatives appear to be any better. A halfassed solution is no solution at all.


Would you mind explaining about this lack of seamlessness?

I can imagine that part of it could be the need of a git clone --recursive, and everybody omits the --recursive if they don't know there are submodules inside the repository. There is another command to pull the submodules later but I admit it's far from ideal.


What's wrong with git submodules?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: