Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Diagnosing why Git is so slow

dscho edited this page Oct 30, 2014 · 3 revisions

Under certain circumstances, Git can become very slow on Windows. Here are a couple of hints to figure out why.

Trace executions in the Bash startup

When starting Git Bash is already slow, edit the file <GIT_HOME>/etc/profile and insert a set -x somewhere at the top. This command will tell Bash to echo the commands it is executing so that you can find out which commands are slow and investigate more closely in that direction.

Activate Git's own tracing

Git often executes subcommands, hence it is possible that you run a certain Git command but the tardiness stems from a different Git command. To find out which commands Git executes internally, set the environment variable GIT_TRACE like so:

GIT_TRACE=1 git stash

Enable the filesystem cache

Windows' filesystem layer is inherently different from Linux' (for which Git's filesystem access is optimized). As a workaround, Git for Windows offers a filesystem cache which accelerates operations in many cases, after an initial "warm-up". You can activate the filesystem cache per-repository:

git config core.fscache true

Avoid inspecting large working trees' modification times

When working with large working trees, Git's (frequent) checking whether files were modified since Git's internal index was last updated can lead to substantial lags. In such a case, it can make sense to switch of this check, but it comes at a price: it requires discipline on the developer's side to keep track which files were changed and git add them explicitly for the next commit (the output of git status will no longer identify modified files). You can disable the check per-repository thusly:

git config core.ignoreStat true