You publish packages/libraries/gems/jars/whatever your language calls them, and a package manager. Needing to combine the actual source trees into a single repo like submodules or subtrees allow you to should be for really rare cases.

That reduces the problem, though it doesn't eliminate it. You'll still run into rough spots when you go to rearrange what files are in what packages.

Say one aspect of a package suddenly starts to grow quite fast and take on a life of its own, and you would like to split it into its own dedicated package (and therefore, it's own repo). How do you do that without loosing the history of those files?

It's possible with git.. but it isn't exactly what I would call straightforward. With a one-repo system you simply move those files to their new location, just like any other file move/rename.

> How do you do that without loosing the history of those files?

I don't know how you did it, but I found `git subtree split` to be an easy solution for extracting a directory into its own repo:

https://github.com/git/git/blob/master/contrib/subtree/git-s...

(It's a shame git-subtree it's still in contrib/, should really be enabled by default. It can also work as git-submodule replacement in some cases, by the way.)

Even if it isn't neatly in it's own tree, you can get away with rewriting commits and some tree objects. It's more complicated, but it can be made to work.

Either isn't as nice as `p4 move ...` though.

But this isn't something that needs to be nice. Files moving between libraries should be rare in well designed libraries, and splitting a subtree out of git is easy enough for when the need does occur.

Keeping a giant repository on the other hand makes it very easy to do stupid things and end up with tightly coupled code. You don't want that to be the path of least resistance.

Advocating a solution that's only simple if all of your code is well-designed all the time is a poor strategy. Everyone has times they don't see the big picture clearly enough, or early enough, to segment or group responsibilities well. Or, even if you see the current big picture clearly, it's difficult to predict how future changes in business goals will change the conceptual model you have for your code today.

I think ultimately, past the scale that you can get with Perforce, that is a problem waiting to be solved by the next generation of VCS.

You can get all your many repos in one place, with all of your internal systems handling them nicely, but moving one file from one repo to another, in a way that history remains clear, is something of an unsolved problem.