Git Status Takes a Long Time to Complete

Viewed 74786

I'm using git to manage files in a local directory on a Windows machine - no network is involved here, I'm not pushing or pulling to/from another machine. My directory has maybe 100 files in it, all test files, pretty small. When I run git status, it regularly takes 20-30 seconds to complete. Is this normal? Is there anything I can do to speed it up, or a better way to see what the state of my repository is (changed files, untracked files, etc)? Other git commands seem to complete much faster.

16 Answers

Have you tried git gc? This cleans cruft out of the git repo.

Running git fsck has resolved this issue for me in the past.

Are you using some kind of virus protection software? Maybe that is interfering with things. git is very fast for me on windows with repositories of 1000's of files.

Have you tried repacking? git-repack.

Otherwise, try duplicating the directory, and deleting the .git folder in the duplicated directory. Then create a new git directory and see if it's still slow.

If it's still slow, then it sounds like a system or hardware issue. Git finishes status on hundreds of files for me in less than 5 seconds.

For me, the slowness was due to having a lot of untracked files (temporary and output files from scripts.) Running git status -uno, which excludes the untracked files, ran much faster, and meets my requirements

Older versions of git have a performance issue with git status - see Ways to improve git status performance for more info.

git 2.13 has 1 fix, and 2.17 more. i moved from 2.7 to 2.23 and it resolved slow status. There is another improvement planned for 2.24 soon.

Another aspect of git status which will be improved (in Git 2.14.x/2.15, Q4 2017) is when it shows ignored files as well (git status --ignored)

"git status --ignored", when noticing that a directory without any tracked path is ignored, still enumerated all the ignored paths in the directory, which is unnecessary.
The codepath has been optimized to avoid this overhead.

See commit 5aaa7fd (18 Sep 2017) by Jameson Miller (jamill).
(Merged by Junio C Hamano -- gitster -- in commit 075bc9c, 29 Sep 2017)

Improve performance of git status --ignored

Improve the performance of the directory listing logic when it wants to list non-empty ignored directories. In order to show non-empty ignored directories, the existing logic will recursively iterate through all contents of an ignored directory.
This change introduces the optimization to stop iterating through the contents once it finds the first file. This can have a significant improvement in 'git status --ignored' performance in repositories with a large number of files in ignored directories.

For an example of the performance difference on an example repository with 196,000 files in 400 ignored directories:

| Command                    |  Time (s) |
| -------------------------- | --------- |
| git status                 |   1.2     |
| git status --ignored (old) |   3.9     |
| git status --ignored (new) |   1.4     |

For more improvment (set in Git 2.17, Q2 2018), see this answer.

In my case there was a huge ZIP file within this git directory. Also *.zip is a line in the .gitignore file:

CMakeCache.txt
CMakeFiles
Makefile
cmake_install.cmake
[...]
*.csv
*.zip
[...]

I have moved this zip file (~915 MB) to some other folder, and this solved the issue.

Often git is extremely slow because of the large number of untracked files.
Try this,

git status -uno

I'm not entirely sure why this is the case, but I had this issue with a repo that uses Git LFS when git-lfs was not installed. I hadn't installed it because I didn't actually need any of the files, but installing git-lfs fixed the speed issue for me.

Try starting with a fresh clone of your checkout.

git clone myrepo mynewrepo

and then do git status in mynewrepo.

Alternatively, and if you are braver, clean out the rubbish from your existing checkout.

git clean -dfx

This avoids git having to scan some (possibly large) set of ignored or not checked-in files.

Related