无响应的 git 状态、差异、添加（挂起）答案

【问题标题】：Unresponsive git status, diff, add (hanging)无响应的 git 状态、差异、添加（挂起）
【发布时间】：2017-09-05 06:17:06
【问题描述】：

以下 git 命令在我的一个存储库中挂起（不响应）：

git status
git diff
git stash
git add

我不能git add 的事实让我相信没有响应不仅仅是由于文件非常大。由于git stash 也挂了，我认为这不仅仅是与源通信的问题。

git remote show origin 显示预期的远程 URL。我正在一个分支上工作，并检查它是否没有被重命名。（FWIW，原点托管在 bitbucket 上。）

以上所有命令在不同的 repo 中都按预期响应，因此不是由于 Internet 连接造成的。

解决此问题的任何其他提示？

【问题讨论】：

GIT_TRACE=1 GIT_CURL_VERBOSE=2 git status 显示什么？你也试过git -vvv吗？
如果您使用的是 Windows，请检查某个 Windows 进程是否锁定了该存储库中的某些文件。如果是这样，您的git 命令将等待其他进程释放锁，然后再继续。如果其他进程永远不放手，Git 永远不会继续。
它在15分钟左右后响应，现在立即响应，没有延迟。正如@torek 所建议的那样，某些文件可能已被锁定。 @torek，我使用的是 Ubuntu 16.04 - 知道如何检查锁定的文件吗？ @jojek， git -vvv 返回“未知选项”。我正在使用 git 2.7.4。您的其他建议返回与 git status 相同的结果，因为它正在工作......
Linux 不会强制锁定非自愿程序，因此 Windows 案例不适用。但是，听起来某些文件由于某种原因具有超级延迟的访问权限。 Linux 支持多种文件系统，包括联网和集群的非本地文件，这些可以任意延迟（基本上是等待某个服务器响应）；也许这就是发生在这里。没有访问系统，很难说更多。
请执行git fsck以验证您的存储库的完整性。

标签： git bitbucket ubuntu-16.04

【解决方案1】：

不管它值多少钱，试试git fsck（根据其中一个cmets）然后git gc。在运行git status 和git commit 时，它们在处理了一些文件后为我挂起；并运行这些命令解决了这个问题。我不知道哪个命令实际上解决了这个问题。

【讨论】：

git gc 对我有很大帮助。我认为fsck 没有做任何事情，因为没有任何损坏的文件。 gc 似乎做了很多清理工作：atlassian.com/git/tutorials/git-gc
在我的情况下，只是运行 git fsck（看到一些 blob 悬空打印输出）有帮助，然后 git status 很快
运行 git fsck 对我来说在一个大型 repo 上花了大约 45 分钟。最后有一个列表，上面有几百行dangling commit 9e9e9e9e9e9e9e9e9ee9e9 (dangling commit <hash>) 和dangling blob <hash> 打印出来的行。我用谷歌搜索找出那些是什么并找到了这个。您可能会发现它也很有用：stackoverflow.com/questions/18514659/….
另请注意，git gc 代表“git 垃圾收集”，我认为它删除了git fsck 报告的所有“悬空提交”和“悬空 blob” .此外，对于任何想知道的人，尽管 git fsck 对我来说花了 45 分钟，git gc 只花了 3 分钟。
现在我已经运行了这两个命令，git status 现在需要 0.9 秒才能运行（使用 time git status 计时），而不是像永远一样冻结。

【解决方案2】：

它在 15 分钟左右后响应，现在立即响应，没有延迟。

使用 Git 2.20（2018 年第四季度），您至少可以检查 git status 是否正在做某事（而不是仅仅停留在那里）：它学会了显示一个 刷新索引时进度条需要很长时间。

参见Nguyễn Thái Ngọc Duy (pclouds)commit ae9af12（2018 年 9 月 15 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 4d87b38，2018 年 10 月 19 日）}

status: 如果刷新索引耗时过长，显示进度条

刷新索引通常很快，但有时仍需要很长时间。

Cold cache 是其中之一。

或将存储库复制到新位置 (*)。

最好显示一些东西让用户知道“git status”没有挂起，它只是在忙着做某事。

(*) 在这种情况下，索引中的所有 stat 信息都变得无效并且 git 回退到重新散列所有文件内容以查看是否有更新索引中的统计信息之间的区别。这是相当昂贵的。即使是像 git.git 这样小的 repo，也需要 3 秒。

【讨论】：

【解决方案3】：

执行 git fsck。就我而言，它已经解决了问题。

【讨论】：

【解决方案4】：

Git 可能正在构建未跟踪文件的索引。在将数千个新文件添加到新克隆的存储库后，git status 似乎挂起超过 2 分钟，然后响应：

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').

如果您遇到类似情况，请考虑将未跟踪的文件移出存储库并确认 git status 再次响应。

【讨论】：

【解决方案5】：

对于任何新手来说，我的都挂在 git add 上——我忘记了我一直在做 pg_dumps 并且在目录中留下了一些大文件。我将它们移动到不同的目录并解决了它。

【讨论】：

【解决方案6】：

我发现我的原因是我从 .gitignore 文件中删除了 /node_module。它在以前的添加中就在那里，所以一旦我重新添加 /node_module，git 就开始正常工作了。

【讨论】：

【解决方案7】：

在我的情况下，帮助我重新启动计算机。

【讨论】：

status: 如果刷新索引耗时过长，显示进度条

`status`: 如果刷新索引耗时过长，显示进度条