Hacker News Reader

Comment by hyperrail | Hacker News Reader

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-o...

View on HN

git 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.

> Hopefully the Microsoft people working on this will find ways to make git on Windows faster

WSL2?

my takeaway of the demo I saw on WSL2 at the Microsoft conference was basically several hours of engineers salivating over how much faster git was on wsl2

>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...

That 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`.

Oh yes, I just tested it out and you're right. Bummer.

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.

You mean like Gentoo (https://github.com/gentoo/gentoo) ? It's not that big either (around 700MB).

That only includes the ebuilds, which are instructions for how to build from source, not the sources themselves.

So the sources for, say, Paint or Edge are versioned within the Windows repository?

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.

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).

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.

https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).

Reply on news.ycombinator.com