我有一个远程GitHub repositories，它使用git-lfs来保存大型二进制文件。
Tyre.objects.filter(car__serial_no__startswith='AB').values('type')
）为了测试其他人如何下载我的存储库，我使用gpfs磁盘以及这些版本的git和git在Linux集群上的高性能登录节点（具有72个Intel Xeon CPU）上运行了以下命令-lfs。
git lfs clone即使在高性能节点上，也花费了近5分钟的时间。而且我注意到输出的最后一行仅在36秒内达到了7.29GB的总容量。其余时间正在运行$ time git lfs clone --progress git@github.com:PackardChan/chk2019-blocking-extreme.git
Cloning into 'chk2019-blocking-extreme'...
remote: Enumerating objects: 138, done.
remote: Counting objects: 100% (138/138), done.
remote: Compressing objects: 100% (114/114), done.
remote: Total 138 (delta 20), reused 138 (delta 20), pack-reused 0
Receiving objects: 100% (138/138), 148.16 MiB | 36.59 MiB/s, done.
Resolving deltas: 100% (20/20), done.
Git LFS: (64 of 64 files) 7.29 GB / 7.29 GB
real 4m51.156s
user 7m14.044s
sys 0m28.360s
（从我从git update-index -q --refresh --stdin命令中学到的东西）。
因此，我认为，如果可以跳过update-index，则可以大大提高性能。如“目标”中所述，如果可以提高速度，那么我不介意放弃git版本控制。
受此post的启发，我尝试了：
top -c但是lfs文件未正确下载。还报告了here。
但是，GitHub doesn't support git-archive。
我尝试过，它并没有表现更好。这是可以理解的，因为我的存储库只有一次提交。
我对git很陌生。所以，我有什么想念的吗？
答案 0 :(得分：0)
我在回答自己的问题。事实证明，问题是我没有运行git lfs install来设置~/.gitconfig。
git lfs install [选项]
执行以下操作以确保已设置Git LFS 正确地：
- 在全局Git配置中以名称“ lfs”设置清洁和污迹过滤器。
- 如果在内部存储库中运行，请安装一个pre-push钩子为当前存储库运行git lfs pre-push。如果“ core.hooksPath”为 在任何Git配置中配置（并且受支持，即 安装的Git版本至少 2.9.0），则预推挂钩将安装到该目录。
在那之后，我从git config --list报告了另外4行配置。
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
现在，time git lfs clone --progress git@github.com:PackardChan/chk2019-blocking-extreme.git的同一命令只需要大约1分钟。