$ git --version --build-options
git version 2.12.2.windows.2
built from commit: 7723f38cfb0e80f010afaebdd9fec4d0822fd2e1
sizeof-long: 4
machine: x86_64
$ cmd.exe /c ver
Microsoft Windows [Version 10.0.14393]
> type "C:\Program Files\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Any other interesting things about your environment that might be related
to the issue you're seeing?
I had Version 2.8 before. It ran very well.
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
All of the above, depending on what I am doing.
(Even if it is somethings simple as a "cd" )
Without more information my gut feeling is to refer to these similar issues: #1070 & #1071
Please see if this changes your situation:
I had the similar issue as yours on my Lenovo e450c laptop. And found the performance turned back to normal when I disabled AMD Radeon graphics driver in Windows device manager and switched to integrated Intel HD graphics.
Okay. That problem is very weird. I looked into your suggestions, and updated the graphic drivers.
After several attempts, restarts and versions, I finally got it to work properly.
However, why is this happening? It's only a shell programm, not a 2D or 3D one!
Okay. That problem is very weird. I looked into your suggestions, and updated the graphic drivers.
After several attempts, restarts and versions, I finally got it to work properly.
However, why is this happening? It's only a shell programm, not a 2D or 3D one!
... 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 interupts and time outs and goodness knows what. Shudders...
Philip
However, why is this happening? It's only a shell program, not a 2D or 3D one!
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 :laughing:
Closing this out as there's not much else we can do here.
Most helpful comment
Without more information my gut feeling is to refer to these similar issues: #1070 & #1071
Please see if this changes your situation: