32

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?

yunque
  • 625
  • 1
  • 8
  • 18
  • 3
    What does `GIT_TRACE=1 GIT_CURL_VERBOSE=2 git status` show? Also have you tried `git -vvv`? – jojeck Apr 10 '17 at 09: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. – torek Apr 10 '17 at 09: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... – yunque Apr 10 '17 at 09: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. – torek Apr 10 '17 at 10:39
  • 3
    Please execute `git fsck` to verify the integrity of your repository. – Lasse V. Karlsen Apr 10 '17 at 10:52

8 Answers8

20

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

  • 2
    `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: https://www.atlassian.com/git/tutorials/git-gc – wordsforthewise Feb 25 '19 at 04:25
  • In my case just running git fsck (saw some blob dangling printouts) helped, then git status was pretty quick – Mercury Jul 09 '19 at 12:28
  • 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 `) and `dangling blob ` lines it printed out. I googled to find out what those are and found this. You might find it useful too: https://stackoverflow.com/questions/18514659/git-what-is-a-dangling-commit-blob-and-where-do-they-come-from/18515113#18515113. – Gabriel Staples Aug 19 '20 at 20:16
  • 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. – Gabriel Staples Aug 19 '20 at 20:53
  • 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. – Gabriel Staples Aug 19 '20 at 20:55
  • 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. – Gabriel Staples Aug 19 '20 at 21:42
  • Is it time to accept this amazing, life-saving answer? :D – dnl-blkv Jan 13 '22 at 14:53
  • git fsck hangs too :( – Jason Cheng Oct 15 '22 at 21:13
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.

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

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

Mayank PATEl
  • 113
  • 2
  • 6
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.

dogstalker
  • 41
  • 2
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.

abestern
  • 31
  • 1
2

In my case what helped was rebooting my computer.

Alexey Kuptsov
  • 86
  • 5
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.

Paschal
  • 725
  • 1
  • 9
  • 17
0

I found mine was:

[status]
    submodulesummary = 1

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

ChrisZZ
  • 1,521
  • 2
  • 17
  • 24