5 ms·

> The biggest drawback of Git is its limited scalability - both in repository and file sizes, and the number of concurrent users. How did you come to the concl

> The biggest drawback of Git is its limited scalability - both in repository and file sizes, and the number of concurrent users. How did you come to the conclusion Git isn't scalable in the number of users? There is no limit in the number of users with Git. There may be limits in the number of interaction between those users, i.e. pull/merge requests, clones, fetches etc. But they are mostly limited by humans. A central system, even a cloud-native system, has far more contention points in operations that are not even interactions between users, i.e. status, commit, etc.

nine_k 3y ago
The number of concurrent merges is definitely a problem. With a few hundred developers committing to the same repo all day, it becomes a chore to make sure that their commits can still be put on top of each other, and that one out-of-sync commit is not holding back a bunch of others which depend on it. This all is solvable, both through discipline and tools. But if a VCS has a built-in capability to alleviate this, it's a good thing.
- funcDropShadow 3y ago
  True, that is one those interactions between users that I mentioned. But the amount of people having the code checked out and poking around its history is only limited by capacity to clone the repository. All other operations are just local. Having hundreds of committers merging into one branch is problematic. Perhaps splitting the repository into smaller parts does have its advantages. Monorepos often have the architectural split of the software while throwing away the advantages of the split at the vcs level. But there is also other large software, developed by hundreds of people, that cannot meaningfully split into separate git repositories without messing about versioning and releasing. The Linux kernel is such a system. They use a loose network of repositories -- mostly a hierarchy -- to pre-aggregate merges. Git is well equipped to handle different approaches -- separation of mechanism and policy. I am looking forward to learn how a central but cloud-native VCS will improve on that.
- __turbobrew__ 3y ago
  The solution to that problem is a merge queue and GitHub supports that now. I do agree that it would be nice if the VCS solved the problem natively, but for many companies GitHub — and not git — is their VCS.
  - sasham 3y ago
    Exactly. The number of companies that implemented their own merge queue is too damn high.

nine_k 3y ago

The number of concurrent merges is definitely a problem. With a few hundred developers committing to the same repo all day, it becomes a chore to make sure that their commits can still be put on top of each other, and that one out-of-sync commit is not holding back a bunch of others which depend on it. This all is solvable, both through discipline and tools. But if a VCS has a built-in capability to alleviate this, it's a good thing.

funcDropShadow 3y ago
True, that is one those interactions between users that I mentioned. But the amount of people having the code checked out and poking around its history is only limited by capacity to clone the repository. All other operations are just local. Having hundreds of committers merging into one branch is problematic. Perhaps splitting the repository into smaller parts does have its advantages. Monorepos often have the architectural split of the software while throwing away the advantages of the split at the vcs level. But there is also other large software, developed by hundreds of people, that cannot meaningfully split into separate git repositories without messing about versioning and releasing. The Linux kernel is such a system. They use a loose network of repositories -- mostly a hierarchy -- to pre-aggregate merges. Git is well equipped to handle different approaches -- separation of mechanism and policy. I am looking forward to learn how a central but cloud-native VCS will improve on that.
__turbobrew__ 3y ago
The solution to that problem is a merge queue and GitHub supports that now. I do agree that it would be nice if the VCS solved the problem natively, but for many companies GitHub — and not git — is their VCS.
- sasham 3y ago
  Exactly. The number of companies that implemented their own merge queue is too damn high.