Reputation: 16291

Git Status Takes a Long Time to Complete

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.

Upvotes: 141

Answers (17)

VonC

Reputation: 1325077

For files you do not version, see also "UNTRACKED FILES AND PERFORMANCE" with git status.

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.

Upvotes: 1

Devyzr

Reputation: 337

In my case, there was an issue with the fact that the internet provider where I'm located doesn't support IPv4.

SSH supports both IPv4 and IPv6 and prefers IPv6 if the DNS retrieves AAAA record, but my ISP doesn't support IPv6, which results in huge delays

I was able to figure this out thanks to giridharkannan over at the atlassian community

They suggest changing the /etc/ssh/ssh_config file so it contains the line:

AddressFamily inet

However, I am using windows. Setting up an IPv4 address did not let SSH ignore IPv6 and it was still taking very long to perform git pulls and git pushes

So, I ended up appending the -4 flag that you can append to ssh to force it to use IPv4, this works for both git pull and git push:

git pull -4
git push -4

This should also work for *nix without needing to change the ssh_config file.

Here is an answer which goes into more detail about how to force git to use either IPv4 or IPv6.

Upvotes: 1

Bill

Reputation: 45426

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

https://git-scm.com/docs/git-fsck

Upvotes: 33

Michael Mior

Reputation: 28762

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.

Upvotes: 0

plhn

Reputation: 5273

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

git status -uno

Upvotes: 2

Scott

Reputation: 7264

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

Upvotes: 199

Alfred Meier

Reputation: 41

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.

Upvotes: 1

M. K. Hunter

Reputation: 1828

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

Upvotes: 9

Brett

Reputation: 6020

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.

Upvotes: 3

thedz

Reputation: 5572

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.

Upvotes: 8

Jack Perry

Reputation: 321

The issue for me was that I had a lot of different repositories cloned onto my local hard drive, the more repos you have the longer it will take to run commands like git status.

I simply deleted a lot of the repos which I no longer needed locally, and my git status went from 1minute~ to 5 seconds.

I can't see any answers similar to this here.

Upvotes: -1

Arigion

Reputation: 3548

My git status was very slow (up to one minute), because the global .gitignore file was located in my windows userprofile, which was stored on an inaccessible network share.

git config --global core.excludesfile
showed something like \\Nxxxx0\User\Username\Eigene Dateien\gitignore_global.txt

For some reason \\Nxxxx0 was inaccessible and my userprofile was loaded from a backup system \\Nxxxxx1. It took some time to figure that out, because usually my userprofile is bound to a drive letter by an enterprise startup script and accessing that drive letter was working as usual. I'm not sure why the git-config used the network share and not the drive letter (probably a younger me is to blame)

After setting
git config --global core.excludesfile $HOME/Eigene\ Dateien/gitignore_global.txt
git status was back to normal speed.

Upvotes: 6

Czar Pino

Reputation: 6314

In my case, slowness was caused by running git status as a different user from the owner of the files in the project.

While not applicable in all instance, a simple chown to your current user may do the trick.

Upvotes: 0

Lex

Reputation: 2096

For some reason git status is particularly slow after moving or copying the repository folder to a new location.

Subsequent runs are usually quicker in this case.

Upvotes: 6

Sarge

Reputation: 2366

On a similar issue I found that having a git repo in a directory below my existing git repo caused a massive slow down.

I moved the secondary git repo somewhere else and now the speed is fast!

Upvotes: 7

Alex Brown

Reputation: 42892

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.

Upvotes: -18

1800 INFORMATION

Reputation: 135295

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.

Upvotes: 13

Git Status Takes a Long Time to Complete

Answers (17)

Improve performance of `git status --ignored`

Related Questions

Git Status Takes a Long Time to Complete

Answers (17)

Improve performance of git status --ignored

Related Questions

Improve performance of `git status --ignored`