我经常遇到存储库损坏的问题。实际上一天几次。当我杀死其中装有jupyter笔记本的内核时，似乎会发生这种情况。我怀疑这里有问题的另一件事是LFS，它是git大文件的扩展名。
在断开状态下，大多数git命令（例如add和status）都在存储库中停止工作。执行命令后，终端将停顿。
发生的另一件事是，一旦我cd进入存储库，zsh（使用git扩展名）也会中断。外壳停滞了，无法恢复。
我想知道一种在这种状态下诊断回购的方法，以找出重复中断的原因是什么。
我并不需要帮助来恢复存储库，因为我有一个备份，可以轻松地重新设置它。但是一天做4次会很烦人...
答案 0 :(得分：1)
我怀疑您做的是同一件事：涉及到Git-LFS。
使用Git-LFS时，存储库中的许多操作，包括使用git add添加文件，都必须借助过滤器进行，Git称之为 smuge 和 clean 过滤器。运行git status并不总是需要任何过滤器，因此可以暗示可能还存在其他问题（而不是也可以），但是过滤器显然是出错的地方。您的Shell可能具有一些Shell魔术，可以在Git存储库中提示（$PS1进行提示，因此它正在运行挂起的Git命令，等待过滤器完成。
在这种情况下，禁用过滤器将演示它，因为事情将再次开始起作用。要禁用过滤器，请小心地将任何.gitattributes和/或.git/info/attributes文件移开。 1 然后将cd放入存储库中，看看是否一切正常。如果是这样的话，不仅是Git-LFS，还包括过滤器。
LFS过滤器通过检查和更改每个Git存储文件的内容来工作，这些文件即存储库数据库中的 blob 对象，它们通过提交及其树存储并列在Git的 index 文件-与工作树中存储的文件的内容进行对比。 small 文件被保留。但是，对于 large 文件，LFS会告诉Git：请不要关注该文件！让我给您一个URL（也许还有一些辅助数据）吧！ LFS通过网络将文件从大型文件存储附件复制到大型文件存储附件，或者复制到大型文件存储附件，而Git只能看到/存储该URL。
如果过滤器进程本身挂起，或者如果大文件存储附件无法访问，则Git只会坐在那里等待，甚至可能永远。如果仍然可以使用存储库的另一个克隆，则必须是LFS附件是 reachable 的情况，因此必须是 filter进程本身陷入困境
您可以查看系统上运行的所有进程，找到卡住的过滤器并终止它。这可能或可能不会使存储库再次正常工作，具体取决于它们被卡住的原因和方式。
1 可能有多个。我还没有玩过Git-LFS。我的理解是，它只使用一个，但这可能是错误的。请注意，过滤器本身是在{{1}中定义的 ，但由于在.git/config或.gitattributes中的条目而被使用。