Git Status Takes a Long Time to Complete

Question

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.

Which git version are you using? Please consider asking for help either on msysGit Google Group, or on git mailing list (git [at] vger.kernel.org, you don't need to subscribe), perhaps this is a bug in git. — Jakub Narębski, Jul 26 '09 at 07:27
Possible duplicate of [Ways to improve git status performance](https://stackoverflow.com/q/4994772/3510513) — dCSeven, Jul 03 '19 at 20:25
See also "[UNTRACKED FILES AND PERFORMANCE](https://stackoverflow.com/a/74889434/6309)" with `git status`. — VonC, Dec 22 '22 at 13:55

score 186 · Accepted Answer · edited Jul 26 '22 at 16:39

186

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

edited Jul 26 '22 at 16:39

PedroC88

3,708
7
43
77

answered Jul 26 '09 at 21:06

Scott

7,034
4
24
26

3

This seems to have done the trick. I'm very surprised though that after only a couple of commits that the repository would have that much stuff that can be cleaned up - thanks! – Matt McMinn Jul 27 '09 at 14:50
5

Hehe, I just ran the `git status` using the `time` command and got a "real" time of 30.464s. I then ran `git gc` then `time git status` once more and got a real time of 35.409s. Pretty strange. – RyanScottLewis Nov 24 '11 at 07:40
22

This fixed me from 33 seconds down to less than 1 second for most of my repositories. It would be nice if Git would tell you to do this when you start getting to that point. I never knew it was needed. – XP84 Jan 28 '13 at 20:10
2

When running `git status` multiple times in a row, the subsequent runs take just fraction of the first one. So, if you are running `git status`, then `git gc` and then `git status` again, it is expected it will run super quick. – kiewic Aug 28 '20 at 23:31
Thanks! I had attempted a few solutions but only this simple one solved the problem. :) – Luis Milanese Jan 18 '23 at 17:59

score 28 · Answer 2 · edited Oct 06 '22 at 12:43

28

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

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

edited Oct 06 '22 at 12:43

Yola

18,496
11
65
106

answered Oct 01 '18 at 19:07

Bill

44,502
24
122
213

4

this worked for me. could explain little more about it. – rahul Jan 29 '21 at 09:20

score 11 · Answer 3 · answered Jul 26 '09 at 05:39

11

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.

answered Jul 26 '09 at 05:39

1800 INFORMATION

131,367
29
160
239

1

Yes, employer mandated TrendMicro OfficeScan. I killed the virus scanner, same results with git status. – Matt McMinn Jul 26 '09 at 08:32
1

Another variant on this theme is on-the-fly encryption software such as Credant, which can make your box remarkably slower. – Don Branson Jul 26 '09 at 21:10
This was the problem for me. Killed Kaspersky antivirus and status was back to <1 second. – Robin Winslow Feb 06 '13 at 14:56
Damn AV - it seems that anti-malware "solutions" cause as many problems as they supposedly solve.. – Michael Burr Jan 28 '23 at 01:27

score 8 · Answer 4 · edited Jun 07 '19 at 01:58

8

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.

edited Jun 07 '19 at 01:58

Harry Cho

2,309
4
20
28

answered Jul 26 '09 at 05:03

thedz

5,496
3
25
29

repack seemed to help - after running it, I ran status, and it returned immediately. However, I waited a few seconds and ran status again, and it took 30 seconds. I tried duplicating the directory, and got the same problem. – Matt McMinn Jul 26 '09 at 05:20
Hmm, interesting. Do you have an external drive? Or a USB flash stick? Try copying the repo over there and see if there's any difference. It's possible there's an issue with the drive it's currently on. – thedz Jul 26 '09 at 07:34
No difference on a USB drive. – Matt McMinn Jul 26 '09 at 08:34
That's really strange. All I can really say at this point is that I don't know. You could try copying your repo and try it on someone else's computer -- that should, at least, tell you if it's a problem local to your system. – thedz Jul 26 '09 at 09:18

score 7 · Answer 5 · answered Feb 02 '12 at 15:00

7

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!

answered Feb 02 '12 at 15:00

Sarge

2,367
2
23
36

1

I add similar problem. What happend is did git init in a subdirectory. The problem of that is then, subdir is kind of hidden (you need to do git status inside to see the changes) but I guess git is still trying to compute them. I ignore the subdir and everything is fine now. – mb14 Jul 18 '13 at 09:45

score 6 · Answer 6 · answered Jan 25 '17 at 16:17

6

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.

answered Jan 25 '17 at 16:17

Lex - Boycott Slack - see bio

1,908
2
19
30

1

Is there a way to avoid this slowness in the first run? I tried git gc,but it didn't help.It's not a problem since it only happens on the first time after copying the files. – franksands Oct 09 '18 at 13:26
I am not aware of a way to avoid the initial slowness, but if there was some command that could do it, it would probably be doing the same thing as the initial `git status` command, so would probably take the same amount of time to complete. – Lex - Boycott Slack - see bio Oct 09 '18 at 14:00

score 6 · Answer 7 · answered Jan 16 '20 at 15:49

6

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

answered Jan 16 '20 at 15:49

M. K. Hunter

1,778
3
21
27

score 5 · Answer 8 · answered Feb 20 '18 at 15:56

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.

score 2 · Answer 9 · answered Sep 28 '19 at 10:01

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.

score 2 · Answer 10 · edited Aug 01 '22 at 19:51

2

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

git status -uno

edited Aug 01 '22 at 19:51

Michael Mior

28,107
9
89
113

answered Jun 29 '22 at 06:57

plhn

5,017
4
47
47

VonC · Answer 11 · 2022-12-22T13:54:08.917

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.

Totally random example here: `node_modules` might be affected by this perf change. Just maybe. — Seth Battin, Jan 10 '18 at 17:00

score 1 · Answer 12 · edited Feb 01 '21 at 13:51

1

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.

edited Feb 01 '21 at 13:51

sɐunıɔןɐqɐp

3,332
15
36
40

answered Feb 01 '21 at 13:07

Alfred Meier

47
4

score 1 · Answer 13 · answered Nov 22 '22 at 19:51

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.

score 0 · Answer 14 · answered Feb 16 '17 at 02:56

0

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.

answered Feb 16 '17 at 02:56

Czar Pino

6,258
6
35
60

score 0 · Answer 15 · answered Aug 04 '22 at 17:29

0

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.

answered Aug 04 '22 at 17:29

Michael Mior

28,107
9
89
113

score -1 · Answer 16 · answered Feb 27 '18 at 05:06

-1

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.

answered Feb 27 '18 at 05:06

Jack Perry

321
1
4
13

1

I don't think this can affect the standard `git status` you run in one directory in any way. If your repositories are checked out into different directories, you can only run `git status` for one of them at a time. It might be a different story if your git repos are overlapping, but that's a bad idea anyways. – Hubert Grzeskowiak Jul 11 '19 at 06:05
@HubertGrzeskowiak it definitely can. They were all over on different places on my hard drive for me but it greatly affected my load times when typing git status. After removing duplicate repositories it immediately became faster from multiple minutes to 5 seconds. – Jack Perry Jul 12 '19 at 07:07

score -16 · Answer 17 · answered Jul 26 '09 at 21:12

-16

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.

answered Jul 26 '09 at 21:12

Alex Brown

41,819
10
94
108

I don't think deleting all your ignored files (what git clean does) would help, it's already ignoring them. More likely running git clean would delete all your configuration files, etc etc. And this command is not undoable. Re-cloning (first saving your old repository in case you need it) is far better than running git clean and has the same effect. – XP84 Jan 28 '13 at 20:12
5

I have to disagree with this answer, running git clean -dfx may break things. – Marcel Valdez Orozco May 18 '13 at 04:07

Git Status Takes a Long Time to Complete

17 Answers17

Improve performance of `git status --ignored`

Linked

Git Status Takes a Long Time to Complete

17 Answers17

Improve performance of git status --ignored

Linked

Improve performance of `git status --ignored`