Unresponsive git status, diff, add (hanging)

Question

The following git commands hang (do not respond) in one of my repositories:

git status
git diff
git stash
git add

The fact that I cannot git add leads me to believe that the unresponsiveness isn't simply due to very large files. Since git stash also hangs, I don't think it's merely a problem with communicating with origin.

git remote show origin shows the expected remote URL. I'm working on a branch and have checked that it has not been renamed. (FWIW, the origin is hosted on bitbucket.)

All the above commands respond as expected in a different repo, so it's not due to the internet connection.

Any other tips for troubleshooting this?

Zayas

What does GIT_TRACE=1 GIT_CURL_VERBOSE=2 git status show? Also have you tried git -vvv? – Noggin

If you are using Windows, check to see if some Windows process has some file or files in that repository locked. If so, your git command will wait for that other process to release the lock, before proceeding. If that other process never lets go, Git never proceeds. – Guaco

It responded after 15 minutes or so, and now responds immediately without delay. It's possible that some files were locked, as @Guaco suggested. @torek, i'm using Ubuntu 16.04 - any idea how to check for locked files? @jojek, git -vvv returns "Unknown option". I'm using git 2.7.4. Your other suggestion returns the same as git status now that it's working... – Zayas

Linux does not force locking onto unwilling programs, so the Windows case does not apply. It does, however, sound like some file had super-delayed access for some reason. Linux supports many kinds of file systems, including networked and clustered non-local files, and these can be delayed arbitrarily long (basically waiting for some server to respond); perhaps that was occurring here. It is hard to say more without having access to the system. – Guaco

Please execute git fsck to verify the integrity of your repository. – Tiki

Answer 1

For whatever it's worth, try git fsck (as per one of the comments) then git gc. When running git status and git commit, they were hanging for me after processing a number of files; and running those commands fixed the issue. I don't know which command actually fixed the problem.

Bulldog

git gc helped a lot in my case. I don't think fsck did anything because there weren't any damaged files. gc seems to do a lot of cleanup: atlassian.com/git/tutorials/git-gc – Purine

In my case just running git fsck (saw some blob dangling printouts) helped, then git status was pretty quick – Thaler

Running git fsck took like 45 minutes for me on a large repo. At the end there was a list of a couple hundred dangling commit 9e9e9e9e9e9e9e9e9ee9e9 (dangling commit <hash>) and dangling blob <hash> lines it printed out. I googled to find out what those are and found this. You might find it useful too: #18515159. – Northnorthwest

Also note that git gc stands for "git garbage collection" and I think it deletes all of those "dangling commits" and "dangling blobs" that git fsck reported. Also, for anyone wondering, even though git fsck took 45 minutes for me, git gc took only 3 minutes. – Northnorthwest

Now that I've run those two commands, git status takes 0.9 seconds to run now (time it with time git status), instead of freezing for what seems like forever. – Northnorthwest

And another note: after running git gc then doing a git commit, I got a message to read and delete the log file in .git/gc.log, and in the log file it said: warning: There are too many unreachable loose objects; run 'git prune' to remove them., so I ran git prune as well, then did rm .git/gc.log to delete that log file. Git said it wouldn't perform automatic garbage collection again until I manually deleted that log file. – Northnorthwest

Is it time to accept this amazing, life-saving answer? :D – Cellaret

git fsck hangs too :( – Galiot

Answer 2

It responded after 15 minutes or so, and now responds immediately without delay.

With Git 2.20 (Q4 2018), you will at least be able to check that git status is doing something (instead of just hanging in there): it learns to show a progress bar when refreshing the index takes a long time.

See commit ae9af12 (15 Sep 2018) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 4d87b38, 19 Oct 2018)}

status: show progress bar if refreshing the index takes too long

Refreshing the index is usually very fast, but it can still take a long time sometimes.

• Cold cache is one.
• Or copying a repo to a new place (*).

It's good to show something to let the user know "git status" is not hanging, it's just busy doing something.

(*) In this case, all stat info in the index becomes invalid and git falls back to rehashing all file content to see if there's any difference between updating stat info in the index. This is quite expensive. Even with a repo as small as git.git, it takes 3 seconds.

Gigantism

Answer 3

Execute git fsck. In my case, it has resolved the problem.

Jaimie

Answer 4

For any newbies, mine was hanging on git add - I had forgotten I'd been doing pg_dumps and had left some large files in the directory. I moved them to a different directory and that solved it.

Disk

Answer 5

Git may be building an index of untracked files. After adding several thousand new files into a freshly cloned repository, git status appears to hang for more than 2 minutes, then responds:

It took 139.67 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').

If you have a similar situation, consider moving the untracked files out of the repository and confirm that git status is again responsive.

Debrahdebrecen

Answer 6

In my case what helped was rebooting my computer.

Signal

Answer 7

I found mine was because I removed /node_module from the .gitignore file. It was there in previous adds so once I re-added /node_module, git started working fine.

Scape

Answer 8

I found mine was:

[status]
    submodulesummary = 1

After comment out this submodulesummary = 1 configuration in ~/.gitconfig file, git status run much faster.

Covington