Question

我有一个git存储库，一开始工作正常（或者在Windows上可以预期的那样好），但是在1周（或者说）之后，当我尝试运行git fetch（和任何一个）时，repo变得越来越慢命令使用fetch）。终端冻结了几分钟，然后开始获取，获取本身不是特别慢，但等待时间使它很痛苦。

我试过了：

转换我的病毒程序
git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256
关闭所有其他应用程序
再次检出存储库（工作几天然后我回来）。
git gc --aggressive --prune=now

任何人都知道我还可以尝试什么，我尝试过google但是我找不到解决方案。

编辑（2015-07-02）：将git gc --aggressive --prune=now添加到测试列表中。

我跑了：

GIT_TRACE=true git pull
trace: exec: 'git-pull'
trace: run_command: 'git-pull'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--is-bare-repository'
trace: built-in: git 'rev-parse' '--show-toplevel'
trace: built-in: git 'ls-files' '-u'
trace: built-in: git 'symbolic-ref' '-q' 'HEAD'
trace: built-in: git 'config' 'branch.develop.rebase'
trace: built-in: git 'config' 'pull.rebase'
trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'
trace: built-in: git 'fetch' '--update-head-ok'
trace: run_command: 'ssh' '-p' 'port' 'user@address' 'git-upload-pack '\''/repo'\''
'
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'

#### WAITING for 2 minutes ####

remote: Counting objects: 59063, done
remote: Finding sources: 100% (124/124)
...

我已经标记了等待时间。

Answer 1

如果延迟在git pull执行（在客户端上）和来自服务器的远程消息remote: counting objects之间，那么服务器端的碎片就是您需要解决的问题。

运行git gc --aggessive将远程存储库打包到您要从中提取的git服务器上的一个或几个packfiles。这些将比选择的对象更有效地加载，这反过来可能会影响获取过程的工作速度。

您运行远程服务器的计算机也可能有某种防病毒扫描程序，它会攻击Git服务器正在加载的每个文件;你拥有的文件越多（碎片越多）问题就越严重。

编辑：更新了答案以指明git gc需要运行的位置，因为碎片式存储库是从中拉出来的，而不是拉到的。

在开始之前，Windows上的Git抓取等待

1 个答案: