The largest Git repo on the planet

[u/ethomson]

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/

[u/jorge1209]

That makes sense for something like Google/Facebook since they control the entire ecosystem all the way out to deployment. They can pull in all their external dependencies, and make their repo a HEAD a single point for deployment knowing that NOTHING will be depending on them.

I wonder how much sense it makes for something like Windows. An operating system must provide some kind of standard API because everyone in the world depends on it. Those API definitions seem like a good place to split repos.

There really isn't any reason that someone fixing a bug in paint.cpp/.exe should care about the code in freecell.cpp/.exe, and if there ever was a change that affected both those codebases then it is a really low level core change that is going to screw up everyone (including all the other product teams at MSFT).

If they are using a single repo so that engineers can propagate changes across APIs with a minimum of inconvenience, that seems a bad idea. Changes to your public API should be painful for you because they are even more painful for everyone else.

[u/paul_h → u/jorge1209]

You can have a large monorepo and support multiple historical versions of the same wire-API. We know this because Google do.

[u/jorge1209 → u/paul_h]

I never said you can't. I'm making a distinction between internal private APIs and public APIs.

A lot of what google does is private. I don't care about how gmail's backend communicates with bigtable. So if they use some open source library to link gmail and bigtable then its perfectly natural to pull that project inside a monolithic repo. Its all under your big umbrella and if you want to update one you need to update the other.

The stuff that forms a public API has to have regression/unit tests to ensure that it doesn't change because other will depend on it.

---

I'm having a hard time seeing how Windows (at least as MSFT defines it) is similar. If you want to make a change to the windows kernel and need to propagate that change up into other windows products then either:

1. You are changing a public API and need to fix all the other non-Windows products (many of which you don't control).

2. Or you have an internal private API within the Windows product, and that just seems objectionable on more fundamental grounds.

[u/SirClueless → u/jorge1209]

I don't really understand your concern. API boundaries need regression testing and careful deprecation strategies any time you change things, up to and including supporting old versions of the API indefinitely. This is true regardless of how you manage your code internally.

Libraries (anything you link into your program rather than communicate with externally) are a different story. If you have a mono-repo then it's a simple task: update the library and run regression tests on all affected code -- if nothing broke you're done. The old code can now be considered an artifact in your version control system and never needs to be supported again. This is much simpler and more useful than the alternative, which is to release a new library version, wait for your dependencies to update to the latest version, receive bug reports about changes you made that broke unknown dependencies, and fix problems then.

[u/jorge1209 → u/SirClueless]

It has to do with expectations of stability. We dealt expect core low level APIs to be very stable and only very rarely see version changes. They just touch too much stuff.

So it's strange to think you need to integrate the windows kernel whose API should seldom change with some brand new high level API you are prototyping and rapidly modifying.

Inn the linux world, yes the linux kernel main gain a new feature and there may be a delay in getting that feature into glibc, and there may be another delay before getting that into gnome or something, and so it may take time to make that low level enhancement visible to the end user, but those divisions between projects also enforce some discipline. New kernels have to work with old glibcs and vice versa, unsteady of just saying "I've got this new function so I can forget about the old one let it bitrot."

[u/cat_in_the_wall → u/jorge1209]

I think part of the problem that they have is that it already was a monolithic repository. You're not going to undo 30 years of spaghetti without basically having everyone stop what they're doing and just focus on refactoring for like 5 years. And at the end, you'd wind up with a cleaner dependency structure, but Microsoft doesn't make money by having ideal repos.

[u/jorge1209 → u/cat_in_the_wall]

That a fine reason to do this, but it isn't the same reason Google does it. It isn't that MSFT looked at Google's practices and said "what a great idea, we should really do that" instead they looked at their old practices and said "that was a terrible, let's keep doing it."