I'm not sure what have been changed, but my Git installation started to be extremely slow on an average-sized repository. Others use Git with the same repository on similar machines.

Various commands working with local files are slow, e.g. status & commit. push is fast.

Windows 10, Git 2.11.0 64 bit, high CPU consumption.

Typical problems and solutions already ruled out:

  • Antivirus
  • Network drive
  • core.fscache

time git status (from git-bash aka MinGW):

real    0m29.017s
user    0m0.015s
sys     0m0.031s

Tracing performance with GIT_TRACE_PERFORMANCE=true git status unfortunately has shown only a single atomic chunk:

performance: 32.583549907 s: git command: git status
  • I cannot speak to your issues in particular, but I recommend starting with prune. It should lighten the load on other operations you attempt. Good luck! – eebbesen Dec 26 '16 at 16:10
  • 1
    compile git (github.com/git-for-windows/git.git) on your own with Visual Studio (github.com/git-for-windows/git/commit/…) to get PDBs. Now open cmd.exe as admin and run this: wpr.exe -start CPU -start ReferenceSet -filemode && timeout -1 && wpr.exe -stop C:\HighCPUUsage.etl. now do your slow git actions. after you did this, go back to CMD and press a key to stop logging. Zip the large ETL + your own generated PDbs for git and share the zip (onedrive share link) – magicandre1981 Dec 27 '16 at 12:15
  • 1
    Unfortunately at some point git become fast again and support engineers are unable to tell me what has been changed in the repo. – kirilloid Apr 7 '17 at 10:14
  • 1
    I can no longer add an answer to this question, but I had the same issue, fixed it, and I want to document it for whoever lands on this page again. Simply upgrading to Git 2.15 from 2.14 (not even opening a new terminal) gave me a 3x git status speedup. I believe it's this: github.com/git-for-windows/git/pull/1344 – alejandro5042 Dec 29 '17 at 23:18
  • 1
    I had this problem because my home folder (containing the .gitconfig) was on a network share. I fixed it by installing MSYS, and then installing git into MSYS with pacman -S git. This works because MSYS has a separate home folder. – jpaugh May 2 '18 at 13:29

This Stack Overflow post worked for me: Git Bash (mintty) is extremely slow on Windows 10 OS

Old question, I know, but I recently encountered the problem and found the answer - so thought I'd proliferate. Essentially, it was an issue with the AMD Radeon Graphics Driver slowing down mintty. Go to Device Manager, and disable AMD Radeon Graphics in favor of Intel Integrated Graphics. I've tried to find out why, but no luck so far.

  • 2
    So did this solution work for you are not because you are writing an answer and if you have not confirmed the posted solution you write about, then it's not really an answer and therefore you should read over "Why do I need 50 reputation to comment" to ensure you understand how you can start commenting. – Pillsbury IT Doughboy Aug 11 '17 at 19:03
  • I had only intel graphic chipset on that machine, so it's like I already did that. Also from my understanding of how modern software utilizes hardware, the chances mintty utilize GPU somehow are pretty slim. There might be a bug in a driver making CPU stuck, but it's also very improbable situation. Ah, and I don't even use minGW console — I use standard windows cmd with executables added to the PATH. – kirilloid Aug 15 '17 at 9:45
  • 1
    Holly... this worked for me. Did you have any luck finding out why this happens? @Abi – pmoleri Oct 6 '18 at 4:46
  • 2
    Disabling your graphics driver!!!!??? Not a solution. – Triynko Feb 1 '19 at 18:45
  • @Triynko, did you read stackoverflow.com/a/43762587? - It is both the accepted answer and the highest voted answer (so far). – Henke Nov 24 '20 at 7:06

If you scenario is like mine, and you don't have an AMD Graphics Driver, then try creating a HOME environment variable which points to your user profile directory (e.g. C:\Users\UserName), as is suggested further down in:

Git Bash Mintty is extremely slow on Windows 10 OS

One caveat... the explanation in that link says to make a new System Environment Variable.

I was able to fix my problem by making a new User Environment Variable, which seems preferable to having a system-wide environment variable pointing to your personal home directory.

The PowerShell way of doing it:

Win+R→type powershellCtrl+Shift+Enter

Set-ItemProperty -Path HKCU:\Environment\ -Name Home -Type String -Value $Env:UserProfile

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.