others - 在 Windows 7 x64,git/bash极其缓慢

我所遇到的问题是Git/Bash总是很慢,我知道在Windows上Git比较慢,但是这太荒唐了。

到目前为止,我尝试过:

  • 添加git 项目文件夹到病毒扫描程序的排除列表
  • 完全禁用我的病毒扫描程序(卡巴斯基2011)
  • 确保Outlook未运行(Outlook 2007 )
  • 关闭所有其他应用程序
  • 以管理员身份运行git
  • 禁用网络连接,启动git并禁用连接
  • 禁用网络连接,启动git,启用连接(仅偶尔运行),
  • 运行git gc
  • 以上的组合

有人是否遇到过类似的问题?

时间:

可以通过运行三个命令来设置一些配置选项,显著加速Windows上的git :


$ git config --global core.preloadindex true
$ git config --global core.fscache true
$ git config --global gc.auto 256

注释:

  • core.preloadindex并行执行文件系统操作,隐藏延迟,在所有平台的未来版本的git (更新)中启用: 在v2.1中启用)

  • core.fscache修复UAC问题(不需要运行git作为管理员)

  • gc.auto将文件中的文件数最小化.git/

你的Bash提示符中是否显示了Git信息? 要测试这个,请尝试在Bash中进行以下临时更改:

 
export PS1='$'

 

我编辑了/etc/profile,它在$PATH:中,


#export PATH="$HOME/bin:$PATH"

这使我的命令运行得更快,可能是因为Git Bash不再搜索可执行文件,我的 /etc/profile 是 c:Program Files (x86)Gitetcprofile

一个是启用并行索引预加载,从命令提示符中:
git config core.preloadindex true
这将time git status从7秒更改为2.5秒。

更新!

不再需要下列内容,自mysysgit 1.9.4起,一个补丁已修复此问题,
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
但是,你必须通过键入
git config core.fscache true

我还禁用了UAC和"luafv"驱动程序(需要重新启动),这将禁用Windows Vista,7和8中的驱动程序,该驱动程序会将尝试写入程序的程序重定向到系统位置,而是将这些访问重定向到用户目录。

要禁用此驱动程序,请点"开始",打开注册表HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv到4以禁用驱动程序,然后,将UAC设置为最低的设置,"从不通知"

这个更改将time git status从2.5秒变成0.7秒。

完全卸载Git,重新启动(经典的Windows治疗)和重新安装Git就是解决方案,一切又快了。

只需将以下代码添加到你的~/.profile (在Win7 : c:/Users/USERNAME/.profile).


fast_git_ps1 () 
{ 
 printf --"$(git branch 2>/dev/null | grep -e '* ' | sed 's/^..(.*)/ {1} /')" 
} 

PS1='[33]0;$MSYSTEM:w07 
33[32m]u@h [33[33mw$(fast_git_ps1)33[0m] 
$ ' 

基于这个博客

我通过设置core.preloadindex获得了一个不错的改进真的推荐 。

我通过以管理员身份运行cmd.exe解决了Win 7 x64上的git缓慢问题。

我已经遇到了将 git for Windows ( checkPermission ) on Windows 7 x64作为有限用户帐户的问题。 从我在这里和其他地方看到的,共同主题似乎是缺乏管理特权和/或者 UAC 。 由于UAC在我的系统上,它试图写入/删除 Program Files 目录中的东西的解释对我来说最有意义。

在任何情况下,我已经解决了我的问题通过安装git的便携版本 1.8 zipinstaller 。 注意,我必须解压. 7 z 分发文件并将它的打包为 zip,以便zipinstaller能够工作。 我还不得不手动将那个目录添加到我的系统路径。

现在的性能很好。 尽管它安装在 Program Files (x86) 目录中,但我没有作为有限用户的权限,它似乎没有遇到同样的问题。 我认为这可能是因为便携版本在写入/删除文件的位置更加保守,可能是这种情况,或者从 1.7到 1.8的升级。 我不打算去决定哪个是原因,足以说它现在工作得更好了,包括 bash 。

使用 (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null


PS1='33[33m]w n[33[32m]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) [33[00m]# '

它并不像__git_ps1那么复杂--例如,当你在.git目录中进行cd时,它并不会更改提示,但是对于日常使用足够了。

...