GIT LFS 卡在 filter-process 命令中
GIT LFS is stuck in filter-process command
我在 Bitbucket 中有一个 GIT 存储库,它使用 GIT-LFS:
每当我尝试克隆存储库时,git-lfs.exe
都会卡在以下命令行中:
"C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process
以下所有情况都会发生这种情况:
- 当我尝试克隆存储库目录时(使用
git clone https://...
)
- 当我尝试将存储库添加为子模块时(当 运行ning
git submodule update
)
- 在我使用 GIT-LFS(然后缺少文件和更改)在存储库的克隆中中止上述任何命令和 运行
git reset --hard
之后。
我正在使用
$ git-lfs --version
git-lfs/3.1.2 (GitHub; windows amd64; go 1.17.6)
$ git --version
git version 2.35.1.windows.2
和
也有同样的问题
$ git-lfs --version
git-lfs/2.12.1 (GitHub; windows amd64; go 1.14.10; git 85b28e06)
我还有其他几个工作目录,其中同一个存储库是一个子模块,运行ning git submodule update
在这些目录中工作正常(但没有任何变化,所以命令实际上没有做任何事)。
更新:按照 中的建议启用跟踪并等待足够长的时间后,结果发现 GIT LFS 在从 LFS 下载实际文件时“卡住了” ,这似乎非常慢(尽管文件的总大小只有大约 1 GB。文件日期表明总下载时间超过 1.5 小时!)。它最终完成,所有文件都在它们应该在的地方。这可能是与 Bitbucket 相关的问题。关于可能导致此问题的任何建议(除了联系 Atlassian 支持)?
(有关如何调试此问题的任何建议也是有效答案)
调试此方法的方法是在执行 Git 操作时在环境中设置 GIT_TRACE=1
、GIT_TRANSFER_TRACE=1
和 GIT_CURL_VERBOSE=1
。 (如果您使用 Git Bash,您可以将 space-separated 添加到 git clone
命令之前。)
这会让您看到 Git LFS 是否真正启动并取得进展。如果是这样,您将能够看到正在发出的请求以及它们是否存在问题。
如果不是,那么事情就更棘手了。我们已经看到一些使用 non-default 防病毒软件的人会看到损坏的情况,因为 Git LFS 是用 Go 编写的,而 Go 二进制文件往往具有非常规结构。 Windows 上的端点监控软件可能会做同样的事情。无论哪种情况,您都应该删除受影响的软件,重新启动,然后只使用默认的防病毒软件。
有时,从服务器获取文件可能非常慢并且需要很长时间,您只能等待它完成。您不必接受这一点,但在某些情况下这可能是您所能做的或可能有时间做的。
如果您不确定它是卡住了还是只是变慢了,请检查 以查看命令在“卡住”时正在做什么。
我在 Bitbucket 中有一个 GIT 存储库,它使用 GIT-LFS:
每当我尝试克隆存储库时,git-lfs.exe
都会卡在以下命令行中:
"C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process
以下所有情况都会发生这种情况:
- 当我尝试克隆存储库目录时(使用
git clone https://...
) - 当我尝试将存储库添加为子模块时(当 运行ning
git submodule update
) - 在我使用 GIT-LFS(然后缺少文件和更改)在存储库的克隆中中止上述任何命令和 运行
git reset --hard
之后。
我正在使用
$ git-lfs --version
git-lfs/3.1.2 (GitHub; windows amd64; go 1.17.6)
$ git --version
git version 2.35.1.windows.2
和
也有同样的问题$ git-lfs --version
git-lfs/2.12.1 (GitHub; windows amd64; go 1.14.10; git 85b28e06)
我还有其他几个工作目录,其中同一个存储库是一个子模块,运行ning git submodule update
在这些目录中工作正常(但没有任何变化,所以命令实际上没有做任何事)。
更新:按照
(有关如何调试此问题的任何建议也是有效答案)
调试此方法的方法是在执行 Git 操作时在环境中设置 GIT_TRACE=1
、GIT_TRANSFER_TRACE=1
和 GIT_CURL_VERBOSE=1
。 (如果您使用 Git Bash,您可以将 space-separated 添加到 git clone
命令之前。)
这会让您看到 Git LFS 是否真正启动并取得进展。如果是这样,您将能够看到正在发出的请求以及它们是否存在问题。
如果不是,那么事情就更棘手了。我们已经看到一些使用 non-default 防病毒软件的人会看到损坏的情况,因为 Git LFS 是用 Go 编写的,而 Go 二进制文件往往具有非常规结构。 Windows 上的端点监控软件可能会做同样的事情。无论哪种情况,您都应该删除受影响的软件,重新启动,然后只使用默认的防病毒软件。
有时,从服务器获取文件可能非常慢并且需要很长时间,您只能等待它完成。您不必接受这一点,但在某些情况下这可能是您所能做的或可能有时间做的。
如果您不确定它是卡住了还是只是变慢了,请检查