They keep every project in a single repo, mystery solved.
Edit:
> We already have some of the easily separable projects in separate repositories, like HPHP.
Yeah, because it makes no sense, it's C++. They probably use for everything PHP i assume then. Is there no good build management tool for it?
That's not true:
> It is based on a growth model of two of our current repositories (I.e., it's not a perforce import). We already have some of the easily separable projects in separate repositories, like HPHP. If we could split our largest repos into multiple ones, that would help the scaling issue. However, the code in those repos is rather interdependent and we believe it'd hurt more than help to split it up, at least for the medium-term future.
They already have multiple repositories, the stats they're doing there is based on "two of [their] current repositories" implying more than two.
Sounds to me like this: http://thedailywtf.com/Articles/Enterprise-Dependency-Big-Ba...
This kind of "Duh, look what you're doing" response isn't really justified.
Sure, splitting up your repository would make things faster, but having to maintain multiple repositories is a major headache for the end-users of git. If it's possible, why not fix its scalability so that you don't have to worry about it?
You tend to split repositories based on team responsibilities. I doubt that every developer needs access to update all million+ files.
What this comes down to is that they've made certain architecture decisions that ideally would be changed but it's not possible to do so at this time.
Also, as Ævar writes in the first response, "there's only so much you can do about stat-ing 1.3 million files".