35

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?

Improve this question
5
  • 4
    What does GIT_TRACE=1 GIT_CURL_VERBOSE=2 git status show? Also have you tried git -vvv? Commented Apr 10, 2017 at 9:22
  • 2
    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. Commented Apr 10, 2017 at 9:26
  • 2
    It responded after 15 minutes or so, and now responds immediately without delay. It's possible that some files were locked, as @torek 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... Commented Apr 10, 2017 at 9:45
  • 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. Commented Apr 10, 2017 at 10:39
  • 3
    Please execute git fsck to verify the integrity of your repository. Commented Apr 10, 2017 at 10:52

8 Answers 8

Reset to default
22

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

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
In my case just running git fsck (saw some blob dangling printouts) helped, then git status was pretty quick
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: stackoverflow.com/questions/18514659/….
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.
git fsck hangs too :(
|
6

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.

Improve this answer

Comments

4

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

Improve this answer

Comments

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.

Improve this answer

Comments

3

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.

Improve this answer

Comments

2

In my case what helped was rebooting my computer.

Improve this answer

Comments

1

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.

Improve this answer

Comments

0

I found mine was:

[status] submodulesummary = 1

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

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.