To be precise, git's scaling issues mostly relate to centralization and file count rather than raw size. * Pushing changes to a central repo requires including

To be precise, git's scaling issues mostly relate to centralization and file count rather than raw size. * Pushing changes to a central repo requires including upstream commits. With 1 commit/s to that central repo, all developers are stuck in a loop until their push succeeds. It is a human spinlock with high contention. * Some algorithms scale linearly with the number of server branches, such as pull-without-specifying-a-branch, which becomes too slow with 100K branches (a consequence of central repos). * Some algorithms are linear with the number of files, like git status. * Binary files don't compress nor deduplicate well, slowing pull and clone. Those issues apply to fossil and Mercurial. cf. https://docs.microsoft.com/en-us/azure/devops/learn/git/technical-scale-challenges https://docs.microsoft.com/en-us/azure/devops/learn/git/tech...