Git Bash在Windows 7 x64上非常慢

在一个小项目的开发过程中，我一直在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个文件。

当前回答

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

2013-08-17 10:49:04

其他回答

结合回答:

威尔伯特- PS1中应该包含哪些信息 Sinelaw 's - (<branch_name>) or (<sha>)

# https://unix.stackexchange.com/questions/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt
# \033 is the same as \e
# 0;32 is the same as 32
CYAN="$(echo -e "\e[1;36m")"
GREEN="$(echo -e "\e[32m")"
YELLOW="$(echo -e "\e[33m")"
RESET="$(echo -e "\e[0m")"

# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackoverflow.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382
fast_git_ps1 ()
{
    git -C . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))"
}

# you need \] at the end for colors
# Don't set \[ at the beginning or ctrl+up for history will work strangely
PS1='${GREEN}\u@\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

结果:

2017-04-23 09:40:46

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