The biggest problem with git is that it is entirely a distributed version control system. In git you are always the client and the server. Your clone, normally,

The biggest problem with git is that it is entirely a distributed version control system. In git you are always the client and the server. Your clone, normally, contains the entire history of development and all branches. In a fully distributed development model like Linux, this is a good design. However, most development is done at least partially centralized where you have a real "source of truth" and everything else is derivative/subordinate to that. In that environment, there is little reason to have the entire history of everything on your machine since you can always call out to the real source. It is the clone having everything that causes problems with binary files and large code repositories since a clone must download the entire universe unless you are very careful. Companies work around this limitation by doing clever virtual filesystem hacks that act as-if you downloaded the whole thing but actually only demand load in things as needed allowing them to transparently work with large repositories without the crippling download/storage costs of every random laptop actually holding the universe. This does not mean we should go back to centralized version control systems where everybody is only a client. In that model you must reach out to the source of truth for everything and every branch only exists if the source has it. No, what we need is a system where you are a client and a subordinate (up to full/peer) server. You pull a subordinate server with as much, temporally and spatially, of the true server as you want. You can then operate as you can in git creating branches and as many local commits as you please with your subordinate server tracking those changes. You can then synchronize the real server with the sub-server as you do in regular old git. The logic should all be basically the same, since sub-server synchronization is actually a simpler, degenerate case of the synchronization of true peers which git does normally. You can also create a chain of sub-servers, what are basically mirrors of various completeness, to support whatever degree of centralization to distributed you want. No, central system, but also not fully distributed; a hierarchy as deep or flat as you want supporting both extremes in one model while incurring minimal structural differences or complexities above the currently used fully distributed model. This provides the development advantages of a monorepo while retaining the infrastructure advantages of the multirepo. You can just create spatial sub-servers for each "logical" repo that the primary development team on that component pulls from normally. If you need to reach outside you pull either multiple sub-servers or the parent. The advantage you get over multirepos is that your sub-servers know they are actually one whole, so pulling multiple "repos" and simultaneous commits will not result in bizarre history tearing or figuring out how to synchronize the disjoint histories, which are some of the major advantages of a monorepo. You can handle binary assets or files easily because you just set the main development sub-server to not include the assets and their history. Maybe you have a test sub-server that when pulled only pulls the current version of the assets and nothing more so you can build the newest version. Not like you need the entire history to build with every random old version of the assets. But again, by having a unified version control for the assets and the code you can know if your local server is out-of-date while still working totally locally until you need to synchronize. While you are at it I guess you can fix the git UX as well, but the real prize is improving the model.