GIT LFS 卡在过滤进程命令中
我在 Bitbucket 中有一个 GIT 存储库，它使用 GIT-LFS：
每当我尝试克隆存储库时，git-lfs.exe 都会卡在以下命令行中：
"C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process
这种情况发生在以下所有情况中案例：
- 当我尝试克隆存储库目录时（使用 git clone https://...）
- 当我尝试将存储库添加为子模块时（运行 git submodule update 时） code>)
- 在我中止上述任何命令之后并且使用 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)
我有几个其他工作目录，其中同一个存储库是一个子模块，并且在这些工作目录中运行 git submodule update 可以正常工作（但没有任何更改，因此命令实际上不需要做任何事情）。
更新：启用跟踪后，按照这个答案中的建议，并等待足够长的时间，事实证明 GIT LFS 是从 LFS 下载实际文件时“卡住了”，这似乎非常慢（尽管文件的总大小只有约 1 GB。文件日期表明总下载时间超过 1.5 小时！）。它最终完成，所有文件都在它们应该在的地方。这可能是与 Bitbucket 有关的问题。关于可能导致此问题的任何建议（除了联系 Atlassian 支持之外）？
（有关如何调试此问题的任何建议也是有效的答案）
I have a GIT repository in Bitbucket, which uses GIT-LFS:
Whenever I try to clone the repository, git-lfs.exe gets stuck with the following command-line:
"C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process
This happens in all of the following cases:
- When I try to clone the repository directoy (using
git clone https://...) - When I try to add the repository as a submodule (when running
git submodule update) - After I abort any of the above commands and run
git reset --hardin the clone of the repository using GIT-LFS (which then has missing files and changes).
I am using
$ git-lfs --version
git-lfs/3.1.2 (GitHub; windows amd64; go 1.17.6)
$ git --version
git version 2.35.1.windows.2
and also had the same problem with
$ git-lfs --version
git-lfs/2.12.1 (GitHub; windows amd64; go 1.14.10; git 85b28e06)
I have several other working directories where the same repository is a submodule, and running git submodule update in these works fine (but there are no changes, so the command doesn't really have to do anything).
UPDATE: After enabling tracing, as suggested in this answer, and waiting long enough, it turned out GIT LFS is "stuck" while downloading the actual files from LFS, which just seems to be extremely slow (despite the total size of the files being only about 1 GB. File dates suggest the total download took over 1.5 hours!). It eventually finishes, and all files are where they should be. This maybe an issue related to Bitbucket. Any suggestions on what could cause this (other than contacting Atlassian support)?
(Any advice on how to debug this issue is also a valid answer)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
调试此问题的方法是在执行时在环境中设置
GIT_TRACE=1、GIT_TRANSFER_TRACE=1和GIT_CURL_VERBOSE=1你的 Git 操作。 （如果您使用的是 Git Bash，则只需将这些以空格分隔的内容添加到 git clone 命令之前即可。）。这将使您看到 Git LFS 是否真正启动并取得进展。如果是这样，您将能够看到正在提出的请求以及这些请求是否存在问题。
如果不是，那么事情就更棘手了。我们已经看到一些情况，使用非默认防病毒软件的人可能会看到损坏，因为 Git LFS 是用 Go 编写的，而 Go 二进制文件往往具有非常规的结构。 Windows 上的端点监控软件可能可以做同样的事情。无论哪种情况，您都应该删除受影响的软件，重新启动，然后仅使用默认的防病毒软件。
The way you'd go about debugging this is to set
GIT_TRACE=1,GIT_TRANSFER_TRACE=1, andGIT_CURL_VERBOSE=1in the environment when performing your Git operation. (If you're using Git Bash, you can just prepend those, space-separated, to thegit clonecommand.).That will let you see if Git LFS is actually starting up and making progress. If so, you'll be able to see the requests being made and if there's a problem with them.
If it's not, then things are trickier. We have seen some cases where people using a non-default antivirus can see breakage because Git LFS is written in Go, and Go binaries tend to have unconventional structure. It's possible endpoint monitoring software on Windows could do the same thing. In either case, you should remove the affected software, reboot, and use just the default antivirus instead.
有时，从服务器获取文件可能非常慢并且需要很长时间，您只需等待它完成即可。您不必接受这一点，但这可能是您所能做的，或者在某些情况下可能有时间做的。
如果您不确定它是否被卡住或只是速度缓慢，请检查此答案以查看该命令在“时正在做什么”卡住”。
Sometimes, getting the files from the server may simply be very slow and take a long time, and you just have to wait for it to finish. You do not have to accept this, but it may be all you can do or may have time for in some situations.
If you are unsure whether it is stuck or just slow, check this answer to see what the command is doing while it is "stuck".