git status command is very slow

Question

My git status command is getting slow recently.

I tried to trace the execution:

GIT_TRACE=1 GIT_CURL_VERBOSE=2 git status

Output:

10:24:26.589696 run-command.c:640       trace: run_command: GIT_INDEX_FILE=.git/index git submodule summary --cached --for-status --summary-limit 1 HEAD
10:24:26.611043 git.c:576               trace: exec: git-submodule summary --cached --for-status --summary-limit 1 HEAD
10:24:26.611744 run-command.c:640       trace: run_command: git-submodule summary --cached --for-status --summary-limit 1 HEAD
10:24:26.688245 git.c:576               trace: exec: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'
10:24:26.688921 run-command.c:640       trace: run_command: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'
10:24:26.712823 git.c:576               trace: exec: git-sh-i18n--envsubst 'usage: $dashless $USAGE'
10:24:26.713851 run-command.c:640       trace: run_command: git-sh-i18n--envsubst 'usage: $dashless $USAGE'
10:24:26.754163 git.c:344               trace: built-in: git rev-parse --git-dir
10:24:26.773008 git.c:344               trace: built-in: git rev-parse --git-path objects
10:24:26.788905 git.c:344               trace: built-in: git rev-parse -q --git-dir
10:24:26.832189 git.c:344               trace: built-in: git rev-parse --show-prefix
10:24:26.847857 git.c:344               trace: built-in: git rev-parse --show-toplevel
10:24:26.865076 git.c:344               trace: built-in: git rev-parse -q --verify --default HEAD HEAD
10:24:26.887339 git.c:344               trace: built-in: git rev-parse --show-toplevel
10:24:26.901182 git.c:344               trace: built-in: git rev-parse --sq --prefix  --
10:24:26.927138 git.c:344               trace: built-in: git diff-index --cached --ignore-submodules=dirty --raw d6f45eab9517deee0ad8c898ec74b6ce876ba9eb --
10:24:26.941160 run-command.c:640       trace: run_command: GIT_INDEX_FILE=.git/index git submodule summary --files --for-status --summary-limit 1
10:24:26.962172 git.c:576               trace: exec: git-submodule summary --files --for-status --summary-limit 1
10:24:26.962895 run-command.c:640       trace: run_command: git-submodule summary --files --for-status --summary-limit 1
10:24:37.013868 git.c:576               trace: exec: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'
10:24:37.014548 run-command.c:640       trace: run_command: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'
10:24:37.035160 git.c:576               trace: exec: git-sh-i18n--envsubst 'usage: $dashless $USAGE'
10:24:37.035863 run-command.c:640       trace: run_command: git-sh-i18n--envsubst 'usage: $dashless $USAGE'
10:24:37.064778 git.c:344               trace: built-in: git rev-parse --git-dir
10:24:37.088144 git.c:344               trace: built-in: git rev-parse --git-path objects
10:24:37.106468 git.c:344               trace: built-in: git rev-parse -q --git-dir
10:24:37.144214 git.c:344               trace: built-in: git rev-parse --show-prefix
10:24:37.163255 git.c:344               trace: built-in: git rev-parse --show-toplevel
10:24:37.184273 git.c:344               trace: built-in: git rev-parse -q --verify --default HEAD
10:24:37.201302 git.c:344               trace: built-in: git rev-parse --show-toplevel
10:24:37.220281 git.c:344               trace: built-in: git rev-parse --sq --prefix  --
10:24:37.249722 git.c:344               trace: built-in: git diff-files --ignore-submodules=dirty --raw --

And I found in the two steps it take 10 seconds:

10:24:26.962895 run-command.c:640       trace: run_command: git-submodule summary --files --for-status --summary-limit 1
10:24:37.013868 git.c:576               trace: exec: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'

My git environment:

macOS 10.13.4 (17E199)
git version 2.17.0

Is there anyone coming into the same issue? I'm not familiar with the details with Git.

Is your repo dirty? What about the staging area? How many files are tracked? Have you tried *git gc*? — Gonzalo Matheu, Apr 27 '18 at 02:49
probably you will get more details if you run the submodule command with GIT_TRACE defined — max630, Apr 27 '18 at 07:22

VonC · Accepted Answer · 2022-12-22T13:54:53.280

7

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

Try first to check if the presence of submodules might influence the git status performance, using the --ignore-submodules[=<when>] option:

git status --ignore-submodules=all

Also, make sure your repo is clone locally, not on a remote drive, which would add latency to any Git operation.

edited Dec 22 '22 at 13:54

answered Apr 27 '18 at 04:38

VonC

1,262,500
529
4,410
5,250

1

thanks @VonC, by add `--ignore-submodules=all` it works fine ! but why checking submodules is slow? – Evans Y. Apr 27 '18 at 05:49
@EvansY. By default, git always check submodule status, but you can configure them to be ignored. – VonC Apr 27 '18 at 06:22
1

You can try to change into the directory of that subrepo, and issue the same analysis command like in the top repository. – Rudi Apr 27 '18 at 06:53

score 4 · Answer 2 · answered Apr 27 '18 at 06:26

4

I am afraid this is not just with git status, maybe the whole git environment is lagging. Check this https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow out.

answered Apr 27 '18 at 06:26

akaMahesh

383
2
9

That link is from 2015, and is no longer relevant. Current performance issue are being addressed, for instance, in https://github.com/git-for-windows/git/issues/1533#issuecomment-384259846. ... for Git for Windows though (the OP is on Mac) – VonC Apr 27 '18 at 07:10

git status command is very slow

2 Answers2