Rohan Bhatia
Rohan Bhatia

Reputation: 2010

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

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.

The screen is stuck like this for 7 seconds

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

Answers (26)

pyjamas
pyjamas

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

J.C.
J.C.

Reputation: 69

If you have tried all the voted answers but no one works, you can try WSL like me.

WSL Ubuntu right click menue

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"

hoto1

enter image description here

Finally, play with git in WSL smoothly.

Upvotes: 0

Neal Garrett
Neal Garrett

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

Paul Wintz
Paul Wintz

Reputation: 2753

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.

Upvotes: 107

user3612690
user3612690

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

Anton Krug
Anton Krug

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

VonC
VonC

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

conhost architecture

And for Windows Terminal, you can see from public pull requests (e.g. microsoft/terminal issue 9744) that it uses DirectWrite.

Upvotes: 18

Gerard Sexton
Gerard Sexton

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

pschild
pschild

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

Atilla Ozgur
Atilla Ozgur

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

Denis S Dujota
Denis S Dujota

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

CervEd
CervEd

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

Luan Persini
Luan Persini

Reputation: 63

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.

Upvotes: 0

Martin819
Martin819

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

kamboj
kamboj

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.

enter image description here

Upvotes: 1

Sumanjit Sengupta
Sumanjit Sengupta

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

Otto G
Otto G

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

Xintrea
Xintrea

Reputation: 388

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.

Upvotes: 2

csharpfolk
csharpfolk

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

Excluded locations window as of version 21

Upvotes: 6

Kostiantyn Ko
Kostiantyn Ko

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

Pramod C V
Pramod C V

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

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

hope this helps!!!!

Upvotes: 7

dko
dko

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

Philip Rego
Philip Rego

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

mark
mark

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

rakwaht
rakwaht

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

VonC
VonC

Reputation: 1326782

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.

Upvotes: 14

Related Questions