Git Bash (mintty) is extremely slow on Windows 10 OS

For me, the solution was to set the HOME variable to my user directory (per this answer) via the following steps:

1. Open Advanced System Settings (see instructions below)
2. Open Environment Variables
3. Under System Variables, click "New..."
4. Enter "HOME" for the variable name and the path to your user directory for the value (for example "C:\Users\jdoe").

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:

1. Open the file explorer
2. Right-click on "Computer."
3. Open Advanced System Settings.

On Windows 11, the steps are slightly different:

1. Open the Start menu (either click the ⊞ button in the lower left corner or type the ⊞ Win key).
2. Type "View Advanced System Settings" in the Search box and hit ENTER.

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

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 and nvapi 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 using DirectWrite (and DirectWrite 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 on DirectWrite for 10 years

You 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 uses DirectWrite.

Try again with:

• the latest Git for Windows you can find, like 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.

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

1. Right click on git bash exe.
2. click on 'run as administrator'
3. type in commands like cd /c/

hope this helps!!!!

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

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

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!

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 

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.

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

For me, the problem was in the installed software Strawberry Perl.

I was using next open-source software for Windows 10:

• OpenSSH
• Putty
• Git for Windows
• Qt 5.12.6

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.

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

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.

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.

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 :)

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.

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.

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).

For me, what fixed was:

1. Update git bash (version 2.34.1+)
2. Run as Admin (so it will run all post-install scripts)
3. Done

After this, my git bash was opening very fast.

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

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.

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.

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.

1. Check your Ubuntu config name in windows terminal.

2. 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.

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.