ChatGPT解决这个技术问题 Extra ChatGPT

Git Bash 在 Windows 7 x64 上非常慢

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

当我说慢时,我的意思是运行 cd 需要 8-25 秒,运行 git 命令需要 5-20 秒,而 ls 有时可能需要长达 30 秒。不用说,这不好玩,更不用说没有生产力了。我知道 Git 在 Windows 上速度较慢,但这很荒谬。

对我来说暂时有效的一种解决方案是禁用我的网络连接(如 this answer 中的建议),启动 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 个文件。

不要气馁,但 Cygwin 在 x64 上非常慢,你最好在 Windows XP 32 位上试试。
在同一个系统上,半年前它并不慢。他们一定改变了什么……
在这里几乎所有机器上:Kaspersky AV 大大减慢了 git 并且“禁用”卡巴斯基被破坏,avp.exe 在完全退出后仍然运行。完全重新安装卡巴斯基通常可以解决后一个问题。

M
Mr Fooz

您可以通过运行三个命令来设置一些配置选项来显着加快 Windows 上的 Git:

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

笔记:

core.preloadindex 并行执行文件系统操作以隐藏延迟(更新:在 Git 2.1 中默认启用)

core.fscache 修复了 UAC 问题,因此您无需以管理员身份运行 Git(更新:在 Git for Windows 2.8 中默认启用)

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


没有帮助我,但帮助了下面提到的导出 PS1='$'。所以我知道对我来说问题是终端线。
2017 年(git 2.12)中完全无用的设置,因为所有这些东西都是默认启用的。但是 git 仍然像狗屎一样缓慢地工作。
将文件限制为 256 个可能会导致一些问题。前两个选项已经在新版本的 git 上启用。
@sonyvizio 什么样的问题?
自动 gc 已记录问题。我会通过 git config --global gc.auto 0 关闭该选项并手动执行 gc。 bugs.chromium.org/p/chromium/issues/detail?id=350413
C
Chris Dolan

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

export PS1='$'

问题在于 $(__git_ps1) ...删除它会使一切都变得超快
对于我们当中的外行来说,这个命令到底是做什么的?你说它是“临时的”,我们如何恢复命令?
还修复了我的性能问题。要永久修复,请编辑 C:\Program Files (x86\Git\etc\profile 并注释掉将 __git_ps1 添加到 PS1 的 if-then-else。
在当前版本 2.18.0 中,我在 /etc/profile 中找不到 __git_ps1 命令。是不是搬到别的地方了?
它似乎已移至 C:\Program Files\Git\etc\profile.d\git-prompt.sh。我在该文件中注释掉了 __git_ps1 并且它运行得更快(但在提示中丢失了分支信息)
A
Alex Weitz

我的 Windows 主目录在网络上,我怀疑是 Git Bash 命令首先查找那里。果然,当我查看 $PATH 时,它首先列出了 /h/bin,其中 /h 是 Windows 文件服务器上的共享,即使 /h/bin 不存在。
我编辑了 /etc/profile 并注释掉将其放在 $PATH 中的导出命令:

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

这使我的命令运行得更快,可能是因为 Git Bash 不再通过网络查找可执行文件。我的 /etc/profilec:\Program Files (x86)\Git\etc\profile


我遇到过同样的问题。我将 HOME="$(cd "$HOME" ; pwd)" 更改为 HOME="$(cd "$USERPROFILE" ; pwd)",现在一切都非常快。谢谢你的提示。
我成功地使用了这个变体:在配置文件中,强制 $HOME 到 $USERPROFILE,删除 $HOMEDRIVE 引用。同样在 Git Bash 快捷方式的属性上,将“Start In”设置为 %USERPROFILE%
这在很大程度上解决了我的问题,但至少从 2.7.2 开始,我发现在 /etc/profile.d/env.sh 中导出而不是直接在 /etc/profile 文件中导出。
非常感谢,对我来说同样的问题,但是我通过创建一个名为 HOME 的(用户)环境变量来修复它,指向我想要的主目录。如果 $HOME 不存在,显然 git bash 将默认为 %USERPROFILE%。在此之后, git bash 快如闪电。
唯一有效的选择是评论中描述的@JHH。添加一个名为 HOME 的 Windows 用户环境变量并定义所需的主目录。 (控制面板 -> 系统 -> 高级系统设置 -> 环境变量)
S
Stefan van den Akker

我发现网络驱动器是性能问题。 HOME 指向慢速网络共享。我无法覆盖 HOMEDRIVE 但这不是我所看到的问题。

通过右键单击桌面上的计算机来设置环境变量->属性->高级系统设置->环境变量添加到用户变量部分

HOME=%USERPROFILE%

这行得通。对于每个遇到网络问题的人来说,这是真正的解决方案。您不必编辑任何配置文件,只需将 HOME 指向它应该的位置。
将 Env User Var HOME 定义为 %USERPROFILE% 不起作用。我定义了 SYSTEM VAR : HOME=C:\Users\myUserName
为我工作!谢谢。我做了类似@colin_froggatt 但在用户环境变量中设置 HOME=C:\Users\myUserName
在 2020 年使用 Windows 10 时,未设置 HOME 变量,给它一个默认值恢复了我之前在 2.28 上糟糕的 git 性能。
这对我有用。谢谢您的帮助!视窗 10
P
Peter Mortensen

在对 Chris Dolan 的回答的扩展中,我使用了以下替代 PS1 设置。只需将代码片段添加到您的 ~/.profile(在 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 秒。

这是基于 this blog post


很好的答案。但是我决定在我的 ~/.bashrc 中重新定义 '__git_ps1()',并且只打印空字符串。它加速了所有 Bash 命令。
我是一个 git 初学者,我想知道这个 fast_git_ps1 和原来相当复杂的 __git_ps1 有什么区别。我认为这适用于大多数“正常”情况,但什么是正常的,这会在哪里失败?
我不知道它会失败的情况。我之前确实使用过 __git_ps1,但注意到了性能问题,所以我试图让 git 做更少的工作来提取显示的信息。
原始 __git_ps1 包括状态信息,而不仅仅是分支名称。例如,如果你处于分离的头部状态,在 git 目录中,在一个裸仓库中,在樱桃采摘或变基或合并的中间......这会更快,但可能会有你会错过的场合这个额外的信息,尤其是作为一个 Git 初学者。
P
Peter Mortensen

虽然您的问题可能是基于网络的,但我个人通过两次修改将本地 git status 调用速度提高了十倍(7 秒以上降低到 700 ms)。这是一个 700 MB 的存储库,其中包含 21,000 个文件和大量的大型二进制文件。

一种是启用并行索引预加载。从命令提示符:

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 中的驱动程序,该驱动程序将尝试写入系统位置的程序重定向,而是将这些访问重定向到用户目录。

要查看有关这如何影响 Git 性能的讨论,请阅读此处:https://code.google.com/p/msysgit/issues/detail?id=320

要禁用此驱动程序,请在 regedit 中将 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv 处的“开始”键更改为 4 以禁用驱动程序。然后,将 UAC 设置为最低设置,“从不通知”。

如果禁用此驱动程序让您(它应该)保持警惕,那么另一种方法是在与您的系统分区不同的驱动器(或分区)上运行。显然,该驱动程序仅在系统分区上的文件访问上运行。我有第二个硬盘驱动器,在我的 C 驱动器上使用此注册表修改运行时,我看到与在 D 驱动器上没有它时相同的结果。

此更改需要 time git status 从 2.5 秒减少到 0.7 秒。

您可能还想关注 https://github.com/msysgit/git/pull/94https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b 以查看针对 Windows 中的速度问题正在进行的其他工作。


这再次揭示了愚蠢和曲折的微软解决方案,在 1968 年以一种简单而优雅的方式在 Unix 中解决的问题。微软的臃肿和缺乏重构/灵活性浪费了多少生产努力、时间和金钱/全世界的胆量?
我记得在 68 年使用 git,那是光荣的。
哈哈,在 Linus 出现的前一年@CharlieBrown
在 git 2.1 stackoverflow.com/a/24045966/4854931 中默认启用
L
Liam

似乎完全卸载 Git,重新启动(经典的 Windows 解决方案),然后重新安装 Git 是解决方案。我还清除了所有剩余的 bash 配置文件(它们是手动创建的)。一切又来得很快。

如果由于某种原因无法重新安装(或不可取),那么我肯定会尝试更改 Chris Dolan's answer 中引用的 PS1 变量;它导致某些操作的显着加速。


重新安装而不重新启动不起作用,卸载 - 重新启动 - 安装工作。谢谢!不过,很高兴知道 bash 为何以及如何变得如此缓慢。
在中间重新安装重新安装对我来说没有任何区别。
@RyanW 恐怕除了上述对我有用的解决方案之外,我无能为力,但由于这个问题似乎还没有永久解决,你可能想与 msysgit 的维护人员联系,看看他们是否能解决找出这个问题的原因。
您究竟清除了哪些 bash 配置文件?
这不是答案的解决方案。当您卸载并重新安装时,某些配置文件可能已更改,这些更改就是答案。如果您只说重新安装是解决方案,那是错误的。其他人可能会卸载并重新安装,配置文件可能相同,这就是为什么它不适用于所有人。
P
Peter Mortensen

我通过使用“以管理员身份运行”启动 cmd.exe 解决了我在 Windows 7 x64 上的缓慢 Git 问题。


这个问题是关于 git bash 的。
您可以以管理员身份运行 git bash;这似乎表明存在 UAC 问题
哇,以管理员身份运行 git bash 大大提高了速度
我不确定为什么这个答案只有 6 票赞成。我认为这个答案完全解决了这个问题。速度有很大的提高。
@vinoth10 好吧,您知道,以管理员身份运行存在问题。出于许多原因,这是一个坏主意,并且对于许多企业用例来说根本不是一种选择。通过提升用户来解决性能问题是一个可怕的解决方案。
P
Peter Mortensen

通过更改以下 Git 配置,您还可能获得非常后续的性能提升:

git config --global status.submoduleSummary false

在 Window 7 x64 上运行简单的 git status 命令时,我的计算机运行时间超过 30 秒。定义此选项后,该命令立即生效。

按照以下页面中的说明激活 Git 自己的跟踪帮助我找到了问题的根源,这可能在您的安装中有所不同:https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow


A
Andy

通过将 core.preloadindex 设置为 true as recommended here,我看到了不错的改进。


P
Peter Mortensen

正如 Chris Dolan 和 Wilbert 的回答中所指出的,PS1 会让你慢下来。

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

它使用 (git symbolic-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's "fast_Git_PS1" answer - 200 毫秒和 400 毫秒要快,所以它可以减少你的一点迟钝。

它不像 __git_ps1 那样复杂 - 例如,当您 cd 进入 .git 目录等时,它不会更改提示,但对于日常使用来说,它已经足够好且速度快了。

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


您也可以使用 --short 选项不打印 refs/heads/
@friederbluemle,您使用的是哪个版本的 git?我的 (1.7.9) 不为 symbolic-ref 命令提供 --short
更新为在任何 git 存储库之外不打印错误,并适用于分离的 HEAD
我正在使用 1.8.4 (msysgit)
P
Peter Mortensen

除了这些其他答案之外,我还通过使用并行子模块获取(自 2016 年初的 Git 2.8 起)加快了具有多个子模块的项目。

这可以使用 git fetch --recurse-submodules -j8 完成并使用 git config --global submodule.fetchJobs 8 设置,或者您拥有/想要使用的内核数量。


A
Alexander Trofimov

只有在设备管理器中关闭 AMD Radeon Graphics(或 Intel Graphics)对我有帮助。

https://i.stack.imgur.com/FOFML.png

我在这里找到了答案:https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=


P
Peter Mortensen

我在 Git Bash 和 Git GUI 中都遇到了同样的问题。这两个程序过去运行良好,但随后它们随机减速到爬行,我不知道为什么。

事实证明,它是 Avast。 Avast 导致各种程序(包括我编写的程序)发生奇怪的事情,所以我禁用了它一秒钟,果然,Bash 现在运行速度和它在 Linux 上一样快。我刚刚将 Git 程序文件文件夹 (C:\Program Files\Git) 添加到 Avast 排除列表,现在它的运行速度与在 Linux 上一样快。

是的,我意识到防病毒软件不是原始帖子中的问题,但我将把它放在这里以防它对某人有用。


M
Michael

综合答案:

威尔伯特的 - PS1 sinelaw 中包含哪些信息 - () 或 ()

# 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}\] $ '

结果:

https://i.stack.imgur.com/t5kmm.png


没有让它更快
@keinabel 此时我会从 blogs.msdn.microsoft.com/devops/2018/06/25/…core.commitGraph=true 和从 blogs.msdn.microsoft.com/devops/tag/git 看其他
P
Peter Mortensen

在我的例子中,Git Bash 快捷方式设置为 Start in:%HOMEDRIVE%%HOMEPATH%(您可以通过右键单击 Git Bash 并选择属性来检查)。这是网络驱动器。

解决方案是使其指向 %HOME%。如果你没有它,你可以在环境变量中设置它,现在 Git Bash 应该快如闪电了。


我认为这个答案应该有更多的选票。我来这里是为了发布同样的建议,但看到你已经打败了我,哈哈。
P
Peter Mortensen

我在 Windows 7 x64 上作为受限用户帐户运行 Git for Windows (msysgit) 已经有一段时间了。

从我在这里和其他地方读到的内容来看,共同的主题似乎是缺乏管理权限和/或 UAC。由于 UAC 在我的系统上已关闭,因此它试图在程序文件目录中写入/删除某些内容的解释对我来说是最有意义的。

无论如何,我通过使用 zipinstaller 安装 Git 1.8 的便携版本解决了我的问题。请注意,我必须解压缩 .7z 分发文件并将其重新打包为 ZIP 文件才能使 zipinstaller 工作。我还必须手动将该目录添加到我的系统路径中。

现在的表现很好。即使它安装在 Program Files (x86) 目录中,我作为受限用户没有权限,但它似乎没有遇到同样的问题。

我将此归因于便携式版本在写入/删除文件的位置更保守(可能是这种情况)或从 1.7 升级到 1.8 的事实。我不会试图确定是哪一个原因,我只想说它现在工作得更好,包括 Bash。


关闭 UAC 似乎为我们解决了问题的“大”部分(多秒延迟)。 ps1 hack 完成了剩下的工作。
同样,我在 SSD、32GB RAM 和四核 i7 上,其他答案都没有帮助,禁用 UAC,重新启动和 git 命令是即时的
P
Peter Mortensen

就我而言,实际上是 Avast 防病毒软件导致 Git Bash 甚至 PowerShell 变得非常缓慢。

我首先尝试禁用 Avast 10 分钟,看看它是否提高了速度,并且确实如此。之后,我在 Avast 中添加了整个 Git Bash 安装目录作为例外,用于读取、写入和执行。在我的例子中是 C:\Program Files\Git\*


我想确认这个提示。从 Avast 中排除 git 确实让事情变得更快。我无需等待即可看到 git status 。赢 7 x64
杀毒软件只会干扰。
谢谢,这绝对是一个快速的胜利!禁用 avast 10 分钟,注意到 git 性能的即时变化(即恢复到正常执行时间)。
这个解决方案对我有用。迈克菲 + Windows 10 Ent。
E
Eugene Pakhomov

如果您从 cmd 使用 Git,请尝试从 Git Bash 运行它。在 cmd 中,git.exe 实际上是一个包装器,每次启动时都会设置正确的环境,然后才会启动真正的 git.exe。做你想做的事可能需要两倍的时间。 Git Bash 仅在启动时设置环境。


G
George

以上没有任何东西可以帮助我。在我的场景中,问题显示如下:

任何 ll 命令都很慢(执行大约需要 3 秒)

任何后续的 ll 命令都会立即执行,但前提是在前一个 ls 命令的 45 秒内。

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

因此,一旦我禁用了防火墙(在我的情况下为 Comodo)并让命令执行,问题就消失了。当防火墙重新打开时,它不会返回。我将尽早更新此响应,详细说明哪个进程正在执行阻塞 DNS 请求以及目标是什么。

BR,G


lllog 的别名?对此会有 DNS 请求似乎很奇怪。
llls -l 的别名。无论如何触发DNS请求仍然很奇怪......同时我仍在等待此问题再次出现以在回复中添加更多详细信息。
P
Peter Mortensen

我的一位同事在 Windows 上遇到了 Git 问题 (7) git status checkoutadd 很快,但 git commit 花了很长时间。

我们仍在努力寻找造成这种情况的根本原因,但是将存储库克隆到一个新文件夹中解决了他的问题。


P
Peter Mortensen

正如许多人所说,这是因为 stash 是 Windows 上的一个 shell 脚本,但从 Git 2.18.0 开始,Windows 安装程序可以选择一个实验性功能,即更快(~90%)的内置版本 stash - https://github.com/git-for-windows/build-extra/pull/203


这对 stash 有帮助,但您的帖子是第一个专门提到 stash 的帖子。它会影响其他 Git 操作吗?
据我了解,没有。预览版中有 2 个实验性功能允许 stash 和/或 rebase 使用本机可执行文件以获得更好的性能,但预览版中的任何内容总是有很小的机会可能会产生小的副作用。
PS 此功能在 v 2.19.1 中已不再预览,因此您不再获得它的选项
r
r g

我也遇到过类似的情况,我的问题与 Active Directory 有关,并且位于 vpn 后面。

干了半年才发现这块金子:http://bjg.io/guide/cygwin-ad/

您基本上只需要在 passwdgroup 部分禁用 /etc/nsswitch.conf 中的 db(您可以在 git 目录中找到它),因此文件如下所示:

# Begin /etc/nsswitch.conf
passwd: files
group: files
db_enum: cache builtin
db_home: cygwin desc
db_shell: cygwin desc
db_gecos: cygwin desc
# End /etc/nsswitch.conf

然后更新您的本地密码和组设置一次:

$ mkpasswd -l -c > /etc/passwd
$ mkgroup -l -c > /etc/group

P
Peter Mortensen

我也遇到了 git PS1 缓慢的问题,尽管很长一段时间以来我一直认为这是一个数据库大小问题(大存储库)并且正在尝试各种 git gc 技巧,并且正在寻找其他原因,就像你一样。但是,就我而言,问题在于这一行:

function ps1_gitify
{
   status=$(git status 2>/dev/null )      # <--------------------
   if [[ $status =~ "fatal: Not a git repository" ]]
   then
       echo ""
   else
       echo "$(ps1_git_branch_name)  $(ps1_git_get_sha)"
  fi
}

为每个命令行状态行执行 git status 很慢。哎哟。那是我亲手写的。我在尝试时发现这是一个问题

export PS1='$'

就像这里的一个答案中提到的那样。命令行速度快如闪电。

现在我正在使用这个:

function we_are_in_git_work_tree
{
    git rev-parse --is-inside-work-tree &> /dev/null
}

function ps1_gitify
{
    if ! we_are_in_git_work_tree
    then
    ...

来自 Stack Overflow 帖子 PS1 line with git current branch and colors,它运行良好。再次拥有一个快速的 Git 命令行。


所以您的问题是由您编写的脚本引起的?对于搜索相同问题的其他用户,也许该脚本不太可能是原因......
看看 OP 问题 - 他提到了很多他检查过的东西,但仍然不是。我也一样。所以在这里我添加了另一件事,当没有任何帮助时要检查。重要的不是我写的这个特定的脚本,而是一个概念——看看你的 PS1。