4 ms·
Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one o
by hyperrail 7y ago
Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system.
On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.
[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
- Arnavion 7y ago>several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value. That one at least is fixed now, by having an option to disable it. https://github.com/git/git/blob/v2.23.0/Documentation/config/status.txt#L15-L18 https://github.com/git/git/blob/v2.23.0/Documentation/config...
- hyperrail 7y agoThat git setting is for `git status`, but I think `git checkout branch` still doesn't have a comparable option either on the command line or in a git configuration file. The closest you can get is to turn off all output with `git checkout -q`.
- Arnavion 7y agoOh yes, I just tested it out and you're right. Bummer.
- Someone1234 7y agoDefinitely 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?
- ldrndll 7y agoI 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.
- vquemener 7y agoYou mean like Gentoo (https://github.com/gentoo/gentoo https://github.com/gentoo/gentoo) ? It's not that big either (around 700MB).
- webstrand 7y agoThat only includes the ebuilds, which are instructions for how to build from source, not the sources themselves.
- vquemener 7y agoSo the sources for, say, Paint or Edge are versioned within the Windows repository?
- hyperrail 7y agoYes, 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.
- usefulcat 7y agoI 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).
- grandinj 7y agogit was deliberately designed around the "known fast" things in Linux. One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache. Since Windows doesn't have an equivalent, git is going to be slower there. Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.