Reputation: 2010
I installed Git on my Windows 10 a couple of months ago. It worked well for some time. But now, it's running very slow.
The git status
command takes 7 seconds to execute, and git stash
takes many minutes for stashing (even if there is nothing to stash). Also, I would like to point out that git status
prints the result instantaneously, but I can not enter a new command for a few seconds, as shown in the image below.
I have tried solutions to similar problems like link1, link2, etc., but none of these have worked.
P.S.: I use Windows Defender antivirus, and it is NOT making my Bash slow. Also, cmd takes more time to execute git
commands while git bash takes longer to run any command.
Update: I have switched to Ubuntu, and therefore, I don't use Windows presently. So, there is no way I can check if any of the solutions work for me. I have accepted the answer provided by @pschild since it has the most upvotes and seems to have worked for many people.
Upvotes: 147
Views: 161628
Reputation: 5408
The solution for me was to comment out everything in these files:
C:\Program Files\Git\mingw64\share\git\completion\git-prompt.sh
C:\Program Files\Git\etc\profile.d\git-prompt.sh
C:\Program Files\Git\etc\profile
C:\Program Files\Git\etc\bash.bashrc
This brought the startup time from 10s to under 1s.
Upvotes: 0
Reputation: 69
If you have tried all the voted answers but no one works, you can try WSL like me.
After installing WSL on your system, you can add WSL-Ubuntu to your context menu. Here are the steps for adding it.
Check your Ubuntu config name in windows terminal.
Download https://github.com/BluePointLilac/ContextMenuManager . It's only in Chinese but you can follow the steps in the figure below. You need to replace Ubuntu-20.04
into your ubuntu config filename.
Command for me: wt.exe -p "Ubuntu-20.04" -d "%V"
Finally, play with git in WSL smoothly.
Upvotes: 0
Reputation: 185
Late to the party but, for me it was with setting the Window->Scrollback lines value too high (100000). I reduced it to 1000 and mintty bash
is performing a lot better.
Upvotes: 0
Reputation: 2753
For me, the solution was to set the HOME
variable to my user directory (per this answer) via the following steps:
Per @Alexandre Jobin's comment, Git Bash can be very slow if your HOME
variable points to a shared network folder. See also the answers to this related question for more solutions.
How to Open Advanced System Settings
On Windows 7 through 10, Advanced System Settings are opened by the following steps:
On Windows 11, the steps are slightly different:
⊞ Win
key).Upvotes: 107
Reputation: 161
None of these solutions above worked for me. Strangely, I noticed that when I was disconnected from the network, git bash would open immediately. I then thought about why the network would matter. When opening a new git bash shell, a user's ENV is configured. This requires getting the current logged in user info. If you are using an active directory remote account (not a local windows account), this information is read from the AD server. If the AD server is inaccessible or your network is slow, opening git bash will hang. If you disconnect your network and git bash works immediately, follow these instructions to create a local /etc/passwd file.
click start
type "git bash"
right click icon, left click "Run as administrator"
# get current user entry and cache it in /etc/passwd
mkpasswd -c > /etc/passwd
# edit nsswitch and comment out "db" to prevent accessing Microsoft AD
vim /etc/nsswitch.conf
passwd: files # db
group: files # db
Upvotes: 4
Reputation: 1781
Similarly to previous answers, I created ~/.config/ssh/git-prompt.sh
file to change the behavior of the existing git-prompt.sh
.
Content of the ~/.config/ssh/git-prompt.sh
:
PS1='\[\033]0;$TITLEPREFIX:$PWD\007\]' # set window title
PS1="$PS1"'\n' # new line
PS1="$PS1"'\[\033[32m\]' # change to green
#PS1="$PS1"'\u@\h ' # user@host<space>
#PS1="$PS1"'\[\033[35m\]' # change to purple
#PS1="$PS1"'$MSYSTEM ' # show MSYSTEM
PS1="$PS1"'\[\033[33m\]' # change to brownish yellow
PS1="$PS1"'\w' # current working directory
if test -z "$WINELOADERNOEXEC"
then
GIT_EXEC_PATH="$(git --exec-path 2>/dev/null)"
COMPLETION_PATH="${GIT_EXEC_PATH%/libexec/git-core}"
COMPLETION_PATH="${COMPLETION_PATH%/lib/git-core}"
COMPLETION_PATH="$COMPLETION_PATH/share/git/completion"
fi
# comment out the line below to make it even faster, but you will not see the current branch
PS1="$PS1 "'\[\033[35m\]`git branch --show-current 2>/dev/null`' # add branch in purple
PS1="$PS1"'\[\033[0m\]' # change color
PS1="$PS1"'\n' # new line
PS1="$PS1"'$ ' # prompt: always $
Previous answers are using git branch
and grep
with sed
, however from git 2.22
it's much simpler, just use the argument --show-current
. This way it's simpler and it can be embedded inline in the prompt instead of depending on another function. It's easier to disable as well, just comment out one line.
In my script, I already commented out my user, host and system from my prompt.
You can run time
command to benchmark to see which works best for you:
time git branch --show-current
And maybe you can compare it to the other alternatives posted here.
Maybe another alternative would be to disable as much fanciness as possible. And have custom .bashrc
with a lot of aliases like alias gbr='git branch'
or something in the lines. The prompt tries to be fancy, but if it's in a way of being usable then rather just call the shortcut of the branch alias command and have an overhead on every single command.
Upvotes: 0
Reputation: 1326782
In response to Lafexlos's bounty:
Disabling AMD Radeon driver solved my issue but I am really wondering on why part.
Would appreciate an answer which focuses on that.
As to why:
Issue 1070 reports.
Bringing up the Radeon settings GUI and clicking on something while waiting for the bash prompt immediately releases something and makes it appear - weird.
AMD was contacted but no response...
This project reports:
But all of the graphic (terminal) output has to be displayed via those drivers.
They (the drivers) get their hooks into all parts of the system with hidden interrupts and time outs and goodness knows what. Shudders..
Issue 1129 adds:
Starting with Windows 7 (maybe Vista?) the console had the ability to display itself via DirectWrite, which is build on top of Direct3D, which is heavily dependent on driver implementations of DirectX API.
As a former NVIDIA employee who worked directly on
nvd3dum
,nvwgf2umx
andnvapi
I can tell you we were rather skeptical of the wisdom of this decision.
Seems AMD should have been more skeptical, perhaps their driver quality would have been better.
On that last point, Dwayne Robinson mentions in the comments:
- The console (
conhost.exe
) in Windows 7 did not display text usingDirectWrite
(andDirectWrite
did not even exist in Vista).
Even Windows 11's conhost still does not use DirectWrite for compat reasons, but the "Windows Terminal" does.- Additionally
DirectWrite
itself had no dependencies on Direct3D, but Direct2D did. *I worked onDirectWrite
for 10 yearsYou can see in this diagram from Windows 10 2018 that conhost still uses Win32 GDI.
And for Windows Terminal, you can see from public pull requests (e.g.
microsoft/terminal
issue 9744) that it usesDirectWrite
.
Upvotes: 18
Reputation: 3210
I enabled FIPS in Local Security Policy for testing recently. Disabling it returned my Git Bash to the usual speed.
secpol.msc -> Local Policies -> Security Options -> System cryptography: Use FIPS 140 compliant cryptographic algorithms, including encryption, hashing and signing algorithms
Upvotes: 0
Reputation: 3138
I recently ran into the exact same issue. After trying all the advice from this thread and a lot of other threads, I finally found a solution here, respectively in the linked issue here.
Disabling AMD Radeon graphics driver in the Windows device manager and switching to integrated Intel HD graphics worked for me - for whatever reason.
In my case, I found sh.exe shell to be significantly faster than bash.exe. You can find sh.exe in git_install_dir/bin.
Hope this helps people having this issue while only having integrated Intel HD graphics!
Upvotes: 99
Reputation: 14721
Following commands worked very well for me. The solution is taken from following post
git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256
Normally, first 2 commands should be enabled by default in latest git versions.
Upvotes: 1
Reputation: 611
Lots of great answers here, BUT, none of these options worked/applied or applied in my case,
if that is the case, go check out the ~/.bash_history
file. Clearing this file, solved my issue.
I check all the proposed solutions here and none of it applied to my situation (path was good, on intel drivers natively, latest version of git-bash-windows etc.)
So i did some digging, and realized that the extreme delay was due to the bash history file getting so large, that it was lagging everything I would do in bash because it was loading the history file and writing to it.
ie: startup, git commands, npm commands, etc. (some slower than others)
Hope this helps in case you're at your wits end like I was :)
Upvotes: 1
Reputation: 4263
It may be due to the default PS1
configuration of git-bash. It's easy to test.
Check PS1
printf "$PS1\n"
which should output something like
\[\]\[\]\u@\h \[\]$... \[\]\w\[\]`__git_ps1`\[\]$
the culprit may be __git_ps1
, let's investigate
time __git_ps1
time __git_ps1
(main)
real 0m0.290s
user 0m0.015s
sys 0m0.030s
We can change our PS1 to something simpler (but faster)
time git rev-parse --abbrev-ref HEAD 2> /dev/null
main
real 0m0.118s
user 0m0.000s
sys 0m0.031s
by adding the following to our .bashrc
# Use simpler git ps1
PS1="$(sed 's@`__git_ps1`@ (`git rev-parse --abbrev-ref HEAD 2> /dev/null`)@' <<< "$PS1")"
This approach is much better than modifying the prompt/ps1 stuff that is bundled with git-forwindows.
while we are at it I would also recommend adding
# Delete git for windows PS1 newline
PS1=$(sed 's@\\n@@g' <<< "$PS1")
which gets rid of the extra newline that causes the first line of less
of output to be scrolled off screen when exiting the pager
Upvotes: 3
Reputation: 63
For me, what fixed was:
After this, my git bash was opening very fast.
Upvotes: 0
Reputation: 535
For me, the solution was to set the HOME environment variable to my Users folder.
Go to Start
- type "environment"
- Select "Edit environment variables for your account"
In the top list, check if HOME
variable is there. If it's there, change it's value. If it's not there, click on New...
.
The Variable name
will be HOME
and Variable value
will be path for example C:\Users\<username>
.
The reason why this helped to me is that by default, the Home directory in my case, was pointing to shared network drive. This was slowing down the GIT, because it was connecting to that network drive.
Upvotes: 1
Reputation: 411
I have been strugling with git bash since 2 months because my colleauge( root problem) told me to store git credentials and I don't know what happend to windows 10 but it screwed up. What I have noticed that whenever it starts it is checking the connection to domain server. here goes my solution. I have removed from these arguments from properties -> start at: %HOMEDRIVE%%HOMEPATH%.
Start -> Search Git Bash -> Open Location of File -> Git Bash -> Right Click -> Properties -> Direct Access -> Start At and remove it whatever you have there.
Upvotes: 1
Reputation: 37
Commands like pull, push, etc. seemed to take forever on git bash. Trying on git windows command line prompted github authentication was necessary (web browser/personal token). On authentication, commands started working fine on git windows and git bash as well.
Issue: https://github.com/git-for-windows/git/issues/3284
Upvotes: 1
Reputation: 770
I was running Windows 10 as a virtual machine (using VMware fusion), and for me, changing from 1 to 2 processor cores in the virtual machine setup (which I discovered was the recommended minimun anyway) fixed the problem. The comment by @chunk_split on @rakwaht's answer points in the same direction (i.e. an issue with concurrent threads or processes slowing things down).
Upvotes: 0
Reputation: 388
For me, the problem was in the installed software Strawberry Perl.
I was using next open-source software for Windows 10:
But, the installator Qt 5.12.6 prompts you to install Strawberry Perl. It seems like this package is needed to automate the creation of software deployment scripts. Strawberry Perl have more open-source software besides the Perl. But in reality in 99% of cases Strawberry Perl installation is unnecessary.
Before uninstall Strawberry Perl, my PATH variable became like this:
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files\PuTTY\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\Users\stepanov_sm\AppData\Local\Microsoft\WindowsApps;
After uninstall Strawberry Perl, my PATH variable became like this:
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\stepanov_sm\AppData\Local\Microsoft\WindowsApps;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files\PuTTY\;
May be, Strawberry Perl overlap binaries/scripts from Git for Windows. Before uninstall Strawberry Perl, the command git --version executed within 45 seconds! After uninstall Strawberry Perl, the command began to be executed instantly.
Upvotes: 2
Reputation: 4290
I have a similar problem but only when I ran git bash
as a normal user, when I started git bash
as an Administrator all commands ran really fast.
In my case it turned out that the problem was caused by F-Secure antivirus. I added directory containing git.exe
to the list of excluded directories (excluded from scanning) and it solved this problem for me.
How to exclude directory: https://community.f-secure.com/t5/Business/Excluding-objects-from-Real-Time/ta-p/66013
Upvotes: 6
Reputation: 2736
Tried everything above that made any sense to me, did not help.
Finally I seem to have fixed the issue. Turned out, Git Credentials Manager for Windows tried to contact my domain controller (that is out of reach since I'm out of the office), and that caused a great delay (30+ seconds) each time I wanted to e.g. git checkout
.
To fix this, just had to disable the Credentials Manager completely, now everything's reasonably fast. This is how to disable it: How do I disable Git Credential Manager for Windows?
Hope this helps the desperate ones, cheers!
Upvotes: 5
Reputation: 107
I had same issue on Windows 7 and Window 10, while using the git bash, any command that I run would take considerable time to execute. Finally after many of head breaking trials, found that issue was due to not running my git bash exe as administrator,
Steps
hope this helps!!!!
Upvotes: 7
Reputation: 361
Disclaimer: Not a fix. But quick workaround.
For some reason after my computer updated-- I didn't have Git bash on my computer so I had to redownload the new one 2.19.2.windows.1 and I had the same issue with every execution taking 5-7 seconds.
I didn't have time to look into all of the links and disable graphics drivers and what not. But I had Git shell installed with Github on my computer and I pulled that up (Windows PowerShell) and I could run everything on there I needed immediately.
Upvotes: 0
Reputation: 648
Is your PATH full of junk? Simple commands were taking 20 seconds or more for me sometimes until I removed unnecessary things from my PATH.
Windows: echo %PATH%
Search "edit environment variables" to change.
Other: echo $PATH
Upvotes: 5
Reputation: 45
Adding process exclusion for bash.exe, cmd.exe and conhost.exe in Windows Defender Exclusions list apparently solved the issue for me on Windows 10 64bit.
Upvotes: 4
Reputation: 3967
I had the same problem once and what I found is that the issue for me was with __git_ps1
, basically a variable that includes status informationlike branch name, detached head state, in the git dir, in a bare repo, in the middle of cherry picking or rebasing or merging.
In order to speed up your git bash, go to $GitHome\etc\profile and comment out the if-then where __git_ps1 is
added to PS1.
Anyway the information that you are commenting out are quite useful, expecially if you are at the beginning with GIT. Here is a faster version, found on the internet and used by me quite succesfully on my system:
fast_git_ps1 ()
{
printf -- "$(git branch 2>/dev/null | grep -e '\* ' | sed 's/^..\(.*\)/ {\1} /')"
}
PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '
Upvotes: 24
Reputation: 1326782
Try again with:
PortableGit-2.12.1-64-bit.7z.exe
(unzip it anywhere you want, no setup)then in a CMD
session, set your PATH
with:
set G=c:\path\to\latest\git
set PATH=%G%\bin;%G%\usr\bin;%G%\mingw64\bin
set PATH=%PATH%;C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\
set your HOME
in that same CMD
session
set HOME=%USERPROFILE%
Finally, type bash
, and see if any Git operation is still slow.
Upvotes: 14