Diagnosing why Git is so slow
Under certain circumstances, Git can become very slow on Windows. Here are a couple of hints to figure out why.
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.
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 stashSometimes the output is too verbose – or the command-line window flashes and closes too quickly to read – to make direct diagnosing of the output practical. In this case, simply redirect the entire output of the Bash to a file, like so:
exec > "$HOME"/Desktop/debug.txt 2>&1After diagnosing the problem, you will want to remove the redirection, otherwise you will not be able to interact normally with the Bash.
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 trueWhen 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 off 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