git does have the ability to do partial history clones and partial repository checkouts.
However, you can surely see that the goals of requiring the code to be in a single repository but requiring the ability to only access part of it at a time are conflicting.
There are numerous ways to assemble a product out of lots of subprojects. It would be ridiculous for something like ubuntu to try to put everything into a single repository when all of the common usage patterns have the users working as if they were independent (and often even under different administrative domains).
In Ubuntu it wouldn't make sense because they're taking most of the code from upstream anyway and it changes slowly; I was just using it to give a sense of scale.
The scenario where a single repository becomes handy is when you want to change a method in a shared library fix all the callers in the same commit, and you can do that because the code isn't public and you know all the callers. (It's much the same reason Linux prefers drivers to be in-tree.)
But I'm not sure I entirely want to defend this model; just pointing out that it exists, and the people who like it aren't going to change how the whole company works just to adopt git.
Comments
git does have the ability to do partial history clones and partial repository checkouts.
However, you can surely see that the goals of requiring the code to be in a single repository but requiring the ability to only access part of it at a time are conflicting.
There are numerous ways to assemble a product out of lots of subprojects. It would be ridiculous for something like ubuntu to try to put everything into a single repository when all of the common usage patterns have the users working as if they were independent (and often even under different administrative domains).
In Ubuntu it wouldn't make sense because they're taking most of the code from upstream anyway and it changes slowly; I was just using it to give a sense of scale.
The scenario where a single repository becomes handy is when you want to change a method in a shared library fix all the callers in the same commit, and you can do that because the code isn't public and you know all the callers. (It's much the same reason Linux prefers drivers to be in-tree.)
But I'm not sure I entirely want to defend this model; just pointing out that it exists, and the people who like it aren't going to change how the whole company works just to adopt git.