我在一个samba共享中有一个repo，它在.git / objects中有1.2G。 当我使用file：// protocol本地克隆该repo时，克隆的repo在.git / objects中获得1.5 GB。 为什么Git这样对我？
然后我尝试了另一个更小的回购。我在stdout中看到Git总是在file：//协议中重新压缩repo的一部分，这可能是原因，但是来自github的https协议没有发生。
从github到本地repo2的https协议：
git clone https://github.com/someuser/somerepo.git ~/repo2
19:39:56.188035 git.c:371 trace: built-in: git 'clone' 'https://github.com/someuser/somerepo.git' 'repo2'
Klone nach 'repo2' ...
19:39:56.211036 run-command.c:350 trace: run_command: 'git-remote-https' 'origin' 'https://github.com/someuser/somerepo.git'
19:39:57.381345 run-command.c:350 trace: run_command: 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' '--check-self-contained-and-connected' '--cloning' 'https://github.com/someuser/somerepo.git/'
19:39:57.400372 exec_cmd.c:116 trace: exec: 'git' 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' '--check-self-contained-and-connected' '--cloning' 'https://github.com/someuser/somerepo.git/'
19:39:57.412380 git.c:371 trace: built-in: git 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' '--check-self-contained-and-connected' '--cloning' 'https://github.com/someuser/somerepo.git/'
remote: Counting objects: 73839, done.
19:39:57.951242 run-command.c:350 trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 122 on SAJTY' '--check-self-contained-and-connected' '--pack_header=2,73839'
19:39:57.960749 exec_cmd.c:116 trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 122 on SAJTY' '--check-self-contained-and-connected' '--pack_header=2,73839'
19:39:57.976259 git.c:371 trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 122 on SAJTY' '--check-self-contained-and-connected' '--pack_header=2,73839'
remote: Total 73839 (delta 0), reused 0 (delta 0), pack-reused 73839
Empfange Objekte: 100% (73839/73839), 21.96 MiB | 112.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (60640/60640), Fertig.
19:44:31.187832 run-command.c:350 trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' '--progress=Prüfe Konnektivität'
19:44:31.190358 exec_cmd.c:116 trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' '--progress=Prüfe Konnektivität'
19:44:31.195362 git.c:371 trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' '--progress=Prüfe Konnektivität'
remote: Total 73839 (delta 0), reused 0 (delta 0), pack-reused 73839
从本地repo2到repo3的文件协议：
git clone file://$HOME/repo2 ~/repo3
19:46:53.852660 git.c:371 trace: built-in: git 'clone' 'file:///home/sajty/repo2' 'repo3'
Klone nach 'repo3' ...
19:46:53.874679 run-command.c:350 trace: run_command: 'git-upload-pack '\''/home/sajty/repo2'\'''
19:46:53.878697 run-command.c:209 trace: exec: '/bin/sh' '-c' 'git-upload-pack '\''/home/sajty/repo2'\''' 'git-upload-pack '\''/home/sajty/repo2'\'''
19:46:53.903236 run-command.c:350 trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 129 on SAJTY' '--check-self-contained-and-connected'
19:46:53.903236 run-command.c:350 trace: run_command: 'pack-objects' '--revs' '--thin' '--stdout' '--progress' '--delta-base-offset'
19:46:53.907238 exec_cmd.c:116 trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 129 on SAJTY' '--check-self-contained-and-connected'
remote: 19:46:53.910226 exec_cmd.c:116 trace: exec: 'git' 'pack-objects' '--revs' '--thin' '--stdout' '--progress' '--delta-base-offset'
19:46:53.915230 git.c:371 trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 129 on SAJTY' '--check-self-contained-and-connected'
remote: 19:46:53.918234 git.c:371 trace: built-in: git 'pack-objects' '--revs' '--thin' '--stdout' '--progress' '--delta-base-offset'
remote: Zähle Objekte: 72156, Fertig.
remote: Komprimiere Objekte: 100% (12623/12623), Fertig.
remote: Total 72156 (delta 59287), reused 72156 (delta 59287)
Empfange Objekte: 100% (72156/72156), 21.65 MiB | 16.91 MiB/s, Fertig.
Löse Unterschiede auf: 100% (59287/59287), Fertig.
19:46:57.648781 run-command.c:350 trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' '--progress=Prüfe Konnektivität'
19:46:57.653804 exec_cmd.c:116 trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' '--progress=Prüfe Konnektivität'
19:46:57.658788 git.c:371 trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet' '--progress=Prüfe Konnektivität'
那么在使用file：// protocol进行克隆时如何禁用重新压缩？ 这浪费了硬盘空间，克隆需要1分钟。我不明白。 我只想拥有与github相同的packfile。
注意1：我知道--local选项会禁用重新压缩，但后来我没有看到进度/下载速度，这在网络连接速度慢的大型仓库中更糟糕。
注意2：我正在使用默认打包和gc设置，我可以在不同的PC上使用多个回购重现这一点。
答案 0 :(得分：1)
您可以尝试查看没有压缩的克隆是否更快而不压缩：
git -c core.compression=0 clone ...
请参阅git config core.compression：
整数-1..9，表示不在包文件中的对象的压缩级别 -1是zlib的默认值 0表示没有压缩，1..9是各种速度/大小权衡，9表示最慢 如果未设置，则默认为core.compression。如果未设置，则默认为1（最佳速度）。
同时确保使用latest Git for Windows（自2017年2月起，2.12可用）
另请参阅“git pull without remotely compressing objects”：
core.compression 0应禁用对packfiles中的松散对象和对象的zlib压缩。它可以为不会压缩的对象节省一点时间，但是你会失去任何文本文件的大小优势 但它不会关闭增量压缩，这是推拉过程中的“Compressing...”阶段。而这更可能是导致缓慢的原因。
pack.window 0设置git在进行增量压缩时会考虑的其他对象的数量。将其设置得低可以改善您的推/拉时间 但是你将失去非图像文件（和git的元对象）的delta压缩的实质性好处。
所以你也可以尝试：
git -c pack.window=0 clone ...
结论是，虽然您可以避免“压缩”阶段，但不建议这样做
最好是disable delta for certain files only through a .gitattributes directive而不是删除所有仓库的增量压缩。