在一个小项目的开发过程中,我一直在Windows和Ubuntu上使用Git,经常在两者之间来回切换。问题是Git Bash总是变慢。

当我说慢的时候,我的意思是运行cd需要8-25秒,运行git命令需要5-20秒,而ls有时需要30秒。不用说,这一点都不好玩,更不用说没有成效了。我知道Git在Windows上比较慢,但这太荒谬了。

对我来说,暂时有效的解决方案是禁用我的网络连接(在这个回答中建议),启动Git Bash,然后重新连接。有时在这样做之后,它会持续快速运行几天,但性能最终总是会下降。我已经在msysgit讨论组,Stack Overflow, msysgit问题列表等上拖了几周,但我还没有能够找到工作的解决方案。

到目前为止,我尝试过:

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

我确实读到一些人成功地禁用了Bash完成,但理想情况下,我希望保持它的活动状态。msysgit版本为1.7.3.1-preview20101002,操作系统为Windows 7 x64。可以预见的是,在Linux上运行同样的东西会像闪电一样快。我只会使用Linux,但我也需要在Windows上运行一些东西(某些应用程序,测试等)。

有人遇到过类似的问题吗?如果有,潜在的问题是什么,解决方案是什么(如果有的话)?

这不仅仅是Git存储库,只是作为参考,我一直在使用Git的存储库非常小:最多4-50个文件。


当前回答

正如Chris Dolan和Wilbert的回答所指出的,PS1会减慢你的速度。

我没有完全禁用(正如Dolan建议的那样),也没有使用Wilbert提供的脚本,而是使用了速度更快的“哑PS1”。

它使用(git symbol -ref -q HEAD || git rev-parse——short HEAD) 2> /dev/null:

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

在我的Cygwin上,这比Wilbert的“fast_Git_PS1”回答要快——200毫秒对400毫秒,所以它可以减少你的提示迟钝。

它不像__git_ps1那么复杂——例如,当你cd到.git目录时,它不会改变提示符,等等,但对于日常使用来说,它足够好和快速。

这是在Git 1.7.9 (Cygwin,但它应该可以在任何平台上工作)上测试的。

其他回答

在Chris Dolan回答的扩展中,我使用了以下替代PS1设置。只需将代码片段添加到~/。配置文件(Windows 7: C:/Users/USERNAME/.profile)。

fast_git_ps1 ()
{
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [\1] / p')"
}

PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

这保留了彩色外壳和显示当前分支名称的好处(如果在Git存储库中),但是在我的机器上速度要快得多,从0.75秒到0.1秒。

这是基于这篇博客文章。

通过设置核心,我看到了一个不错的改善。按照这里的建议,Preloadindex设为true。

Bash提示符中是否显示Git信息?如果是这样,也许您无意中在每个命令上都做了太多的工作。为了验证这一理论,请尝试在Bash中进行以下临时更改:

export PS1='$'

以上这些都不能帮助我。在我的场景中,问题是这样表现的:

任何ls -l命令都很慢(大约需要3秒才能执行) 任何后续的ls -l命令都会立即执行,但前提是在前一个ls命令的45秒内。

在使用Process Monitor进行调试时,发现在每个命令之前都有一个DNS请求。

因此,只要我禁用防火墙(在我的情况下是Comodo)并让命令执行,问题就消失了。当防火墙重新打开时,它不会返回。有了最早的机会,我将更新这个响应,提供有关哪个进程正在阻塞DNS请求以及目标是什么的更多详细信息。

我的一个同事在Windows(7)上使用Git时遇到了麻烦,Git状态检查和添加都很快,但是Git提交却花了很长时间。

我们仍在试图找到这个问题的根本原因,但克隆存储库到一个新文件夹解决了他的问题。