Why Your IDE's Git Status Is Slow (and How to Fix It)

If your IDE feels laggy in a large repo, the most common culprit isn’t your editor — it’s the editor’s Git integration polling git status over and over. This article explains what’s happening and the one fix that almost always solves it.

What your IDE is doing

Every modern code editor with Git integration runs roughly this loop in the background:

every 1–3 seconds:
  for each open folder that's a Git repo:
    run `git status --porcelain`
    diff against last result
    update gutter decorations
    update sidebar badges

In a small repo this is fine — status returns in 5ms and the IDE redraws. In a 100,000-file monorepo, each status call walks the working tree for 800ms+. Your editor is paying that cost on every poll, often across multiple open repos.

The symptoms:

• The IDE is unresponsive shortly after launch.
• Indexing seems to never finish.
• A fan kicks on when you have several large repos open.
• Switching branches in the terminal causes a 10-second IDE freeze as it catches up.

If any of those sound familiar, you have an IDE-Git-polling problem.

The wrong fixes

People try a few things that don’t actually help:

• Disabling the IDE’s Git integration. Works, but you lose gutter decorations. This is throwing the baby out with the bathwater.
• Excluding folders from the IDE. Helps a little, but the IDE still polls Git for the included folders.
• Adjusting poll interval. Some IDEs expose this; lowering it means the gutter is stale, which annoys you in a different way.
• Buying a faster machine. Modest improvement at best. The bottleneck is filesystem syscalls, which don’t get much faster with faster CPUs.

The right fix: fsmonitor

git status --porcelain is exactly the operation fsmonitor accelerates. With a v2 helper, the same poll loop becomes:

every 1–3 seconds:
  for each open folder:
    run `git status --porcelain`       # returns in 10–30ms instead of 800ms
    diff against last result
    update gutter decorations

Same code. Same poll interval. 50× less wall-clock time. The IDE is none the wiser.

With gity

cargo install gity
gity register /path/to/your/repo

That’s it. Every IDE running on that machine, in any language, that polls git status now gets the fast answer. The next time your IDE polls, it returns in tens of milliseconds. CPU drops. Fans stop. You stop noticing the IDE is even running.

With Git’s built-in fsmonitor

git config core.fsmonitor true
git update-index --fsmonitor

Also works. See our comparison for the tradeoffs.

Editor-specific notes

VS Code

VS Code runs git status every 5 seconds by default, plus on every focus change and every file save. In a large repo with git.enableSmartCommit on, it also fetches when you open the file panel.

Settings to tune (in case fsmonitor alone isn’t enough):

"git.autoRefresh": true,
"git.autorefresh": true,
"git.decorations.enabled": true

The "git.experimental.fastFsCheck" flag, if your version supports it, biases the polling toward fsmonitor-aware behaviour.

IntelliJ / JetBrains IDEs

JetBrains products use a custom Git plugin that does both polling and inotify-watched updates. With fsmonitor enabled in .git/config, the polling path is fast. The watched path uses a separate filesystem watcher.

If IntelliJ also feels slow at indexing, check Settings → Version Control → Git → Use credential helper and disable any auto-fetch you don’t need.

Sublime Merge / Sublime Text

The plugins (GitGutter, SublimeGit) call git status directly via subprocess. fsmonitor accelerates them with no configuration.

Neovim / Vim

Plugins like gitsigns.nvim and vim-gitgutter poll the same way. fsmonitor accelerates them transparently. For very large repos, also consider let g:gitgutter_async = 1 (the default in recent versions) to keep status checks off the UI thread.

What about file watchers in the IDE?

Most IDEs also have their own filesystem watcher (separate from Git) to know when files change on disk so they can offer to reload. That watcher and Git’s fsmonitor watcher coexist fine — they both subscribe to the same kernel APIs.

The one wrinkle: on Linux, both watchers consume inotify watches. If you have many large repos open and cat /proc/sys/fs/inotify/max_user_watches returns 8192, you’ll exhaust the budget. Bump it:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

This is the single most common cause of “my IDE stopped noticing file changes.”

TL;DR

1. Install gity (or enable Git’s native fsmonitor).
2. gity register <repo>.
3. Your IDE is now fast.

You don’t need to change any IDE settings. The polling loop hasn’t changed; it just gets a faster answer.

If the speedup is dramatic for you (and on monorepos it usually is), tell your team. The biggest barrier to fsmonitor adoption is that nobody knows it exists.