Definitely sounds like a problem. Do you think an alternative source control solution would handle that situation better? At some point huge with a large number of small files takes its toll.
It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?
I believe the difference is that the Linux kernel itself is not that big a project. Windows is a lot more than just a kernel; it’s more akin to having the source code for an entire Linux distribution in one repo.
Yes, most of the components and files in a default Windows installation are built from sources in the main Windows OS git repo.
Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.
The Windows tree is unlike the Linux tree in that the Windows tree is the entirety of Windows, not just the kernel. Not having to check out the entire tree is why GVFS was made.
I read an article a while back about why git is slower on windows than on linux (probably linked from HN, but I can't find it just now) and the TLDR is that it's because the windows filesystem (not just NTFS, but everything around it) has many customization points, and for that reason git will always be slower on windows regardless of the particular underlying FS (as in, adding windows support for, say, ext4 wouldn't fix the problem).
It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?