Hacker News Reader

Comment by ericfrederich | Hacker News Reader

This may be the thing that gets Google to switch. They like having every piece of code in a single repository which Git cannot handle.

Now that it is somewhat proven, maybe Google will leverage GVFS on Windows and create a FUSE solution for Linux.

View on HN

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.

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

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

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.

What's wrong with git submodules?

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.

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.

Google already has a FUSE layer for source control: http://google-engtools.blogspot.com/2011/06/build-in-cloud-a...

Google used to have a Perforce frankenstein, but now they have their own VCS.

Piper is their perforce-like server. You check out certain files, as you'd with p4, work on the tree using git, with reviews, tests, etc. You periodically do a sync which is like pull - - rebase. Then you push your changes back into the perforce-like monorepo.

also they do all the development in one branch / in the trunk https://arxiv.org/abs/1702.01715 ( I never understood the explanations as to why they do that )

Now the article says that with windows they do branches.

They use mercurial (or were), which is as good as git. In fact, I bet a lot of people at Google are happy to use mercurial instead of git, given git's bad reputation with its command line interface.

They don't use mercurial.

You're thinking of Facebook if I'm not mistaken.

I had seen several sources that affirmed that Google used Mercurial, but I'm not sure to what extend, so I will retract it :-)

I'm sure there are a few teams that use Mercurial incidentally somewhere, but our primary megarepo is all on a VCS called Piper. Piper has a Perforce-y interface and there are experimental efforts to use Mercurial with Piper. Also mentioned in the article below, there's limited interop with a Git client.

If you're curious what it all ends up looking like, read this article. It's a fairly good overview and reasonably up to date.

https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

IIRC, the git client is deprecated; the mercurial one is meant to replace it for the use cases where you would want a DVCS client interfacing with Piper in the first place.

It's not deprecated. I use git-multi every day, much to the chagrin of my reviewers. Google thinks that long DIFFBASE chains are weird and exotic, and Google doesn't like weird and exotic as a rule.

Reply on news.ycombinator.com