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

Question

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.

Bungle

Is it only GIT? Are you on a network drive, or a SSD? Do you observe random lag while using your computer? – Honkytonk

yes it is only GIT, everything else is fine. I m not on a network drive or SSD – Bungle

It's been a long time since I booted windows, but try the id command. If that takes a long time, ... I forget how you fix that, but it's at least something I've seen – Vanburen

I was using Git-2.28 which was slow, I downgraded it to Git-2.26.2-64-bit, It is much faster. I am not sure why. – Pigeonhole

Answer 1

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!

Maryland

Anyone have any ideas why disabling the AMD driver helps? I'm struggling to make the connection between how the driver was affecting the performance of git bash. If I had to guess I would assume that maybe it has someone to do with the rendering of the content in the git bash window. Otherwise, as suggested @bySamo is it a bug in the driver? The only connection I can make between the AMD driver and the git bash program is the rendering of the window. Any thoughts? I guess it could be something to do with the requests they make. – Hatband

My suggestion is to open a support ticket for the AMD driver. I did the same a while ago for a problem in the Intel HD driver (not about Git, something completely different) and Intel could reproduce the problem and is working on a solution now. Probably the producer of the hardware and drivers has a much better idea about finding out what is happening there if you can make the problem reproduceable for him by providing all necessary hardware, sofrtware and driver version information. – Heptateuch

The bug is that the AMD driver delays process destruction by 1 second per process. (I identified the bug using Process Monitor.) Updating the driver fixes this issue. – Cresset

I've been using super-slow Git for a week now b4 I finally saw this answer. Seeing git status finally complete in a few milliseconds is almost magical to me XD – Monarski

In my case it is the command prompt that is sluggish. I reinstalled my drivers, as follows. I googled for "26.20.11008.1007" 1909 site:ftp.hp.com and found ftp.hp.com/pub/softpaq/sp101501-102000/sp101604.html. To download the driver I replaced the suffix .html with .exe: ftp.hp.com/pub/softpaq/sp101501-102000/sp101604.exe. It was worth a trial but unfortunately it did not work - the sluggishness is back (after a few days). – Short

I thought I nailed it yesterday, by following the advice at answers.microsoft.com/en-us/windows/forum/…. But sadly, the sluggishness persists. I cannot even reproduce it - it tends to happen when I haven't used my laptop for several hours, typically every morning. (I may have to give up!) – Short

Today I tried AppAudioConfig to help me remove the registry key that allows Console Windows Host to play sounds: right-click Console Windows Host > Open In RegEdit and I deleted that key in the registry. Before: i.imgur.com/YyI3Wec.png. After: i.imgur.com/EGCSZ8F.png. I intend to report back in a week or so to tell whether this was the solution. – Short

git-cmd.exe was significantly faster for me – Bravery

@bySamo In my case, I disabled NVIDIA GPU rather than AMD. Hence, it is not necessarily an AMD bug. This worked, but have no idea why. – Benue

Answer 2

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.

Socher

At the time of this problem, I already had a HOME environment variable. – Bungle

My problem was that my HOME folder was on a shared network folder. Since that we work mostly in VPN, GIT was very slow to read the .gitconfig file. Probably due to the slow protocol over VPN. Now that my home is on my local hard drive, everything is fast again. – Rhinitis

This helped speed things up for me, notably I had a "Home" variable rather than "HOME" which was causing issues with other utilities too. Updating it to HOME fixed a bunch of issues. – Siffre

See also: Change the location of the ~ directory in a Windows install of Git Bash. The solution I used was to add HOME="/c/Users/$(whoami)" to the very top of my C:\Users\my_username\AppData\Local\Programs\Git\etc\profile file. See my full answer here for details. – Xavierxaviera

Answer 3

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

Usa

I meant yes the ps1 changed but git is still slow – Bungle

On my environment, I had to edit the $GIT_HOME/etc/profile.d/git-prompt.sh and remove the line PS1="$PS1"'``__git_ps1``' (~line 31). This worked like a charm. – Serene

I just did PS1='$ ' and that made it run much faster on Windows 10. – Measure

Wish there could be multiple accepted answers. It seems like there are multiple issues that can cause performance problems with git bash. Some issues cause commands like git status to take multiple seconds to execute. Other issues cause a delay in returning to the prompt after commands execute. It seems like most of the various completely unrelated answers here helped somebody. For me, the __git_ps1 fix did the trick. – Stier

I have one that's much faster. The core issue here is largely based on the fact that it's forking multiple processes every single time it's generating the prompt in the PS1 variable. The solution is to use pure bash. See gist here (and my modified version which leverages PROMPT_COMMAND): gist.github.com/Ragnoroct/c4c3bf37913afb9469d8fc8cffea5b2f – Matos

Indeed. Run __git_ps1 to see how much delay it is adding to your PS1 prompt. - I get 2-3 seconds. Exacerbated by HOME being on a network. To get almost instant PS1 updating I moved my HOME off network AND used a faster git branch script (no forking) from here: gist.github.com/Ragnoroct/c4c3bf37913afb9469d8fc8cffea5b2f – Sayers

To check if your PS1 is slow, try setting it to just $ using PS1='$ ' and then executing commands. – Suffumigate

git branch --show can probably be used nowdays to get the current branch name even faster. – Velvetvelveteen

@Matos thanks for your link. I made a small mod so that it handles branch names with / in it, so line 34 becomes: ref:*) branch="$(echo ${head} | awk -Fheads/ '{print $2}')" ;; – Zosi

Answer 4

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.

Enplane

I appreciate your effort to write up an answer but top voted answer already has these link in it so unfortunately this doesn't add anything new, at least for me. – Mangonel

Answer 5

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.

Enplane

will I have to uninstall my last version version of git? It was also 2.12.1 but that wasn't portable git – Bungle

@RohanBhatia No; this is a portable version: just uncompress it anywhere you want. You can have multiple version of Git that way. Only your PATH needs to be adjusted. – Enplane

@RohanBhatia Does your PATH include only Git and System32 Windows folders? And is your view located in drive C:\? (or is it accessed through a shared network path?) Does git status takes a long time in a CMD session? (a s opposed as a git bash session) – Enplane

you can see my path variables and other environment variables here. Not clear on what you mean by view being located in drive c, but my program files and everything else is in drive C. Yes, unfortunately git status takes almost as long to execute git status or any other git command. – Bungle

@RohanBhatia no need for environment variable Windows. Simply open a CMD, type the 'set' commands I mentioned, cd to your view, and try a git status there (no bash needed) – Enplane

I did open cmd and used those set commands and still git status took 3 secs like i wrote earlier in my first comment – Bungle

@RohanBhatia can you copy the result of the command set PATH (from your CMD where you typed those set commands)? – Enplane

here is what it looked like. See git status was slow enough for me to snip the result from the screen.. – Bungle

@RohanBhatia I see your installation path for Git is on F:\. Try instead uncompress github.com/git-for-windows/git/releases/download/… on the C:\ drive, not F:\ drive. – Enplane

No luck.. Git status still takes equal time as before – Bungle

@RohanBhatia How about trying git status in an actual Git repo (on the C:\ drive)? cd /C/path/to/a/git/repo – Enplane

git status is still as slow. Even cd takes more time than usual. – Bungle

@RohanBhatia Does a cd done in the CMD session (ie without typing bash, ie not in a bash session) slow as well? Is the git status done in that CMD session (ie no bash) slow as well? – Enplane

No cd executes just fine on cmd without bash.. but git status is still slow on cmd(might be slightly faster).. So to test I just wrote git stash in a git repo with no extra changes over a commit. And it took 1 min for git stash to tell "No local changes to save". in cmd without bash – Bungle

even when I use autocomplete(pressing tab) to complete a branch name while using git checkout in cmd with bash, it takes 10 seconds to execute that – Bungle

@RohanBhatia forget bash for now: the fact it is slow in a CMD session, without typing bash, means something on Windows slow it down: typically an anti-virus or firewall. – Enplane

but I am using windows defender nothing else – Bungle

Can you install and open Process explorer, and see if you have any process which might hog a lot of CPU? (technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) – Enplane

I dont think so .. This is what process explorer show – Bungle

@RohanBhatia even when sorting by CPU? – Enplane

yep sorting by cpu shows 80-90% for systemidleprocess – Bungle

@RohanBhatia OK: can you show me the result of git config --show-origin -l, to see if there is some git configuration that could be problematic? – Enplane

@RohanBhatia then try again after applying the configs listed in https://mcmap.net/q/13183/-git-bash-is-extremely-slow-on-windows-7-x64 – Enplane

Its time for my class, I will be available after 5 hrs. Thnx for helping me – Bungle

I don't know if this is related but once I reinstalled git and then it was working fine until I restarted my laptop.. – Bungle

@RohanBhatia It should not matter, but you can try that again, and use the Git setup github.com/git-for-windows/git/releases/download/…, to see if a Git used through that installation improves anything (before restarting the laptop) – Enplane

It didn't when I reinstalled it again this time. – Bungle

@Henke Regarding git bash alone, did you try it with a simplified PATH and Git 2.29 (released yesterday)? github.com/git-for-windows/git/releases/tag/v2.29.0.windows.1 – Enplane

@Henke OK. I would be curious to know if the SO community has some solution for you, if you were to describe your case in its own separate question. – Enplane

@Henke Is it with Git for Windows 2.29.0 or 2.29.2? – Enplane

Answer 6

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

Funiculus

Can you explain why this is fixing the problem. Why should user privilege cause such performance improvement? – Pie

I strongly recommend against this approach – Suffumigate

I just tried this after trying many things and the difference was immediate. I agree that this is probably not best practices, but the impact of the change cannot be ignored. Thanks! – Upton

Answer 7

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

Digamma

Answer 8

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

Avidin

on windows this is set path btw. – Incisure

superuser.com/questions/1070994/… also want to reference this one here. I think cleaning especially the intel stuff, made my shell faster – Poona

On a different Win7 AD computer it's taking 2 seconds every time I press enter. CMD works fast. MinGW, Cygwin slow. Intel graphics. Tried all the answers, driving me crazy. – Avidin

Answer 9

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!

Keelboat

Answer 10

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.

Matriculation

Answer 11

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

Suffumigate

Answer 12

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

Lagunas

You may need to adjust your home directory location. If you look at /etc/passwd and the home location is /home/USERNAME and that directory isn't your home area, change it to something that exists like: /c/Users/USERNAME – Lagunas

Answer 13

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.

Staunch

I looked into each possible solution reported here - most didn't apply or didn't help. I have Strawberry Perl installed (compiling Qt), and I think this was the change that fixed my problem. The slowness is actually in 'sh.exe'. Git invokes it - so I was seeing slowdown in both opening a shell as well as invoking 'git'. The AMD driver change didn't apply to me (I have an NVidia graphics card). Things in .bashrc, .bash_profile, /etc/profile were not it, as I tested with empty ones. My AV already had the Git dir excluded. It seems removing C:\Strawberry\c\bin from my PATH was the fix. – Clinton

Answer 14

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

Remainderman

Answer 15

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.

Tarnish

Answer 16

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.

Sigmoid

Answer 17

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

Sedan

if this happens it's very likely you have a bash history configuration that is suboptimal and it may just keep being an issue – Suffumigate

Answer 18

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.

Mixture

Answer 19

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

Macklin

Answer 20

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.

Mojgan

Sorry, can you please clarify: are you saying run the installer as admin or just run git bash as admin after installing the update? – Hexapod

Run the git bash as admin after updating – Mojgan

It did, but sourcetree isn't affected even if running it as admin – Few

Answer 21

Upgrading to Windows 11 resolved this problem for me. Git console is now as fast as a native command prompt or powershell console. So, if

1. You are peeved enough about the slow git console, and
2. Your system is a personal computer that meets the upgrade 11 requirements,
3. You don't mind these changes/deprecations,

I say give it a try.

Tombouctou

Answer 22

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.

Brocket

Answer 23

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

Nessa

Answer 24

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.

Equine

Answer 25

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.

Commonweal