Git Bash is extremely slow on Windows 7 x64

Question

I've been using Git on both Windows and Ubuntu during the development of a small project, frequently flipping back and forth between the two. The issue is that Git Bash consistently becomes slow.

When I say slow, I mean that running cd takes anywhere from 8-25 seconds, running git commands take from 5-20 seconds, and ls can take up to 30 seconds sometimes. Needless to say, this is not fun, not to mention unproductive. I know Git is slower on Windows, but this is ridiculous.

The one solution which has worked--temporarily--for me has been to disable my network connection (as suggested in this answer), start Git Bash, and then reconnect. Sometimes it continues to run quickly for days after doing that, but the performance always degrades eventually. I've trawled through the msysgit discussion group, Stack Overflow, msysgit issue list, etc. on and off for weeks, but I haven't been able to turn up solutions which work.

So far, I've tried:

Adding Git & project folders to the virus scanner's exclusion list
Disabling my virus scanner completely (Kaspersky IS 2011)
Ensuring that Outlook is not running (Outlook 2007)
Shutting down all other applications
Running Git Bash as administrator
Disabling network connection, starting Git Bash, and keeping connection disabled
Disabling network connection, starting Git Bash, re-enabling connection (works only occasionally)
Running git gc
And combinations of the above

I did read that a couple of people had success disabling Bash completion, but ideally I'd like to keep that active. The version of msysgit is 1.7.3.1-preview20101002 & the OS is Windows 7 x64. Running the same things on Linux is, predictably, lightning fast. I would use Linux exclusively, but I need to run stuff in Windows, too (certain applications, testing, etc.).

Has anyone encountered a similar issue? If so, what was the underlying problem and what was the solution (if any)?

This extends beyond just the Git repositories, but just for reference, the repositories I've been using Git with have been pretty small: ~4-50 files maximum.

Not to discourage you but Cygwin is very slow on x64, you better try it on Windows XP 32bit. — ismail, Dec 19 '10 at 21:22
possible duplicate of [Msysgit bash is horrendously slow in Windows 7](http://stackoverflow.com/questions/2835775/msysgit-bash-is-horrendously-slow-in-windows-7) — childno͡.de, Nov 05 '13 at 07:29
On same system, it wasn't slow a half year ago. They must've changed something... — Tomáš Zato, Jan 16 '14 at 00:04
On virtually all machines here: Kaspersky AV massively slows down git *and* "disabling" Kaspersky is broken, avp.exe's still run after exiting it completely. Complete reinstall of kaspersky usually fixes the latter problem. — peterchen, Jan 20 '14 at 10:33
See msysgit's wiki page on this: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow — Drew Noakes, Feb 19 '15 at 11:45
I found the answer that works for me here: http://stackoverflow.com/a/9172824/544779 -- It was the antivirus software! — Mörre, Jun 18 '15 at 15:38
If you are in a network environment (i.e. corporate office), and %HOMEDRIVE% is set to a network drive (which is set by Active Directory), then you should see @mahacoder's solution down below. My own solution was very similar to his. — Jon, Oct 25 '19 at 16:49

score 434 · Answer 1 · edited Oct 28 '18 at 15:20

434

You can significantly speed up Git on Windows by running three commands to set some config options:

git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256

Notes:

core.preloadindex does filesystem operations in parallel to hide latency (update: enabled by default in Git 2.1)
core.fscache fixes UAC issues so you don't need to run Git as administrator (update: enabled by default in Git for Windows 2.8)
gc.auto minimizes the number of files in .git/

edited Oct 28 '18 at 15:20

Mr Fooz

109,094
6
73
101

answered Jun 04 '14 at 19:30

shoelzer

10,648
2
28
49

Didn't help me, but helped the export PS1='$' mentioned below. So I know for me the problem is the terminal line. – Koshmaar Feb 08 '16 at 10:52
78

Completely useless settings in 2017 (git 2.12) because all this stuff is enabled by default. But the git still works slowly like a shit. – ieXcept Apr 05 '17 at 19:45
1

Limiting files to 256 may cause some problems. And the first two options already enabled on new versions of git. – nPcomp May 10 '18 at 15:28
@sonyvizio What kind of problems? – shoelzer May 17 '18 at 12:38
Automatic gc has documented problems. I would turn that option off by ```git config --global gc.auto 0``` and do gc manually. https://bugs.chromium.org/p/chromium/issues/detail?id=350413 – nPcomp May 17 '18 at 15:17
@sonyvizio That's an old, closed issue with no comments for over two years and the `git gc` issue seems to have been resolved a while before that. I don't think it's relevant unless you're running a really old version of git. – shoelzer May 17 '18 at 15:37
Thanks. Speed has been improved with this solution. But not upto linux git command. – rashok Sep 18 '18 at 13:27

score 112 · Answer 2 · answered Dec 19 '10 at 22:10

112

Do you have Git information showing in your Bash prompt? If so, maybe you're inadvertently doing way too much work on every command. To test this theory try the following temporary change in Bash:

export PS1='$'

answered Dec 19 '10 at 22:10

Chris Dolan

8,905
2
35
73

1

After making that change, changing directories became an instant op and `ls` is down to about 6 seconds. Git is noticeably faster as well, down to about 6 seconds for `branch` and `status` for example, instead of 10-15 seconds. – Gemini14 Dec 20 '10 at 00:22
2

@Gemini14 - Good. That means that your Bash shell was configured to do some excessive work in the shell prompt. You'll want to tweak your ~/.bashrc or ~/.login to make the change permanent. Still, a 6 second `ls` is crazy slow, so there's still something quite wrong with your machine. I recommend playing with some of the SysInternals tools on your Windows box to watch what files are being opened. http://technet.microsoft.com/en-us/sysinternals/default – Chris Dolan Dec 20 '10 at 01:58
@Chris Dolan I didn't spot any strange files being opened up, but I did notice that when running any `git` commands or `ls`, multiple bash child processes (sh.exe) opened up (anywhere from 2 to 4). I have no idea if that is normal behavior, but commands which are slow seem to open more child processes. – Gemini14 Dec 20 '10 at 04:26
@Gemini14 - that's not good. Definitely not normal! Other than the bash prompt, I can't think of any reason why that would happen. Just to nail this down, can you post the `PS*` variables when you type `set` at the bash prompt? – Chris Dolan Dec 20 '10 at 20:03
@Chris Dolan Sure thing, PS1 = '$', PS2 = '> ', PS4 = '+ ', and PSMODULEPATH = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'. The PS1 variable is what shows after making the original change you mentioned earlier. – Gemini14 Dec 21 '10 at 00:47
I have the same issue. It looks like the regular bash commands take some time (`ls`, `cd`, ...) then the command in `PS1` take some more time. I timed `ls` and got 2.14 s, but then some more (not measured) time while bash was trying to generate the string in `PS1`. After changing `PS1` to `'$'`, `ls` is just as slow, only I don't need to wait for the prompt anymore. I tried reinstalling (without restart) with no luck, I'll do it with restart. – Gauthier May 05 '11 at 06:28
Wonderful. This worked better than the higher rated answer here: http://stackoverflow.com/questions/2835775/msysgit-bash-is-horrendously-slow-in-windows-7 – Robin Winslow Sep 07 '12 at 09:50
Same extreme slowness w Git/Win7, in Git Bash and via IntelliJ. (Very new to Git, weak 'nix guy, please excuse...) Typing set/Enter in Bash gets 6.5k worth of stuff that looks like environment vars and actual functions. One curious item is this: magicfile=C:/WinApps/Git/mingw/share/misc/magic.mgc. My install is at C:/WinApps/Git/, but there's no mingw dir there, and no magic.mgc file anywhere in that hierarchy. Function-looking examples: __git_aliased_command, __git_aliases, __git_complete, etc. Doing export PS1='$' changed _= to _=PS1, nothing else. Is this normal? Ideas? – enigment Nov 25 '12 at 16:26
1

I'm using oh-my-zsh on Win7, and even hitting enter without running any command was very slow. Fixed by removing the call to `git_prompt_info` from the prompt. – tomger Jul 23 '14 at 07:56
Works EXTREMELY well. The default PS1 is "broken" = "\[\033]0;$MSYSTEM:${PWD//[^[:ascii:]]/?}\007\]\n\[\033[32m\]\u@\h \[\033[33m\]\w $(__git_ps1)\[\033[0m\]\n$" – Hendy Irawan Apr 07 '15 at 03:24
16

Problem is with `$(__git_ps1)` ... removing this makes everything superfast – Hendy Irawan Apr 07 '15 at 03:27
13

For the uninitiated amongst us, what exactly does this command do? You say it's "temporary", how do we revert the command? – Immortal Blue May 06 '15 at 09:07
This worked for me. Really simple but overlooked by many..`__git_ps1` is doing way more work for every command than needed. – R G May 13 '15 at 04:33
6

Also fixed my performance problems. To fix permanently, edit `C:\Program Files (x86\Git\etc\profile` and comment out the if-then-else where `__git_ps1` is added to `PS1`. – Tom Jun 29 '15 at 11:12
Yes the cause is the git prompt, configure it either in /etc/profile, or in ~/.bashrc. I rewritted the PS1 for my problem, but unfortunatly, whenever I launch a git command, a have to wait 1 second: https://gist.github.com/pdemanget/b04c691bbd50f9ab6275 – pdem Jul 20 '16 at 10:36
@ImmortalBlue How to undo: probably simply open another terminal. The prompt calls bash functions which call git multiple times to see whether the current location is in a git archive and if yes, on which branch. Usually involves filesystem traversal (slow when paging, i.e. with too little RAM and a slow disk). – Peter - Reinstate Monica Jul 20 '17 at 17:13
7

In the current version 2.18.0 I canot find the __git_ps1 command in /etc/profile. Has it moved somewhere else? – keinabel Sep 10 '18 at 11:05
16

It seems to have moved to C:\Program Files\Git\etc\profile.d\git-prompt.sh. I commented out __git_ps1 in that file and it went much faster (but lost branch info in prompt) – Miyagi Sep 19 '18 at 11:20

score 93 · Answer 3 · edited Jun 06 '19 at 10:38

93

My Windows home directory is on the network, and I suspected that Git Bash commands were looking there first. Sure enough, when I looked at $PATH, it listed /h/bin first, where /h is a share on a Windows file server, even though /h/bin doesn't exist.
I edited /etc/profile and commented out the export command that puts it first in $PATH:

#export PATH="$HOME/bin:$PATH"

This made my commands run much faster, probably because Git Bash is no longer looking across the network for the executables. My /etc/profile was c:\Program Files (x86)\Git\etc\profile.

edited Jun 06 '19 at 10:38

Alex Weitz

3,199
4
34
57

answered Aug 09 '11 at 14:27

Rob Johnson

939
6
2

6

I had the same issue. I changed `HOME="$(cd "$HOME" ; pwd)"` to `HOME="$(cd "$USERPROFILE" ; pwd)"`, and now everything is blazingly fast. Thanks for the tip. – Jon Sagara Oct 06 '11 at 18:06
2

I was successful using a variation of this: in the profile, force $HOME to $USERPROFILE, removing the $HOMEDRIVE reference. Also on the properties of the Git Bash shortcut, set "Start In" to %USERPROFILE% – Aidan Ryan Dec 07 '11 at 21:24
in the window you can path is: C:\Program Files (x86)\Git\etc\profile – Falaque Dec 12 '13 at 11:14
I had similar issue. When I booted my system connected to LAN, the homedrive used to get set as U:\ which was a network drive. Any commands issued in git bash used to be written to the file .bash_history which was network mapped (and extremely slow). So, I now boot my system without connecting to network and the homedrive is now set to C:\. Its so much faster now. – shyam_prakash Dec 14 '13 at 19:00
12

This fixed my issue for the most part, but with Git at least as of 2.7.2 I found that export in /etc/profile.d/env.sh instead of directly in the /etc/profile file. – Jared Siirila Mar 29 '16 at 17:28
17

Thanks so much, same problem for me, however I fixed it by creating an (user) environment variable called HOME, pointing to my desired home directory. If $HOME is not present, apparently git bash will default to %USERPROFILE%. After this, git bash is lightning fast. – JHH Apr 14 '16 at 09:00
7

The only option which worked for was the one @JHH described in the comments. Add a Windows user environment variable called HOME and define your desired home directory. (Control Panel -> System -> Advanced system settings -> Environment Variables) – RenRen Apr 12 '17 at 13:39
2

Following up on @JHH's comment, the HOME environment variable needed to be a Windows path rather than a Unix-style path on my system. – cxw Apr 25 '19 at 14:30

score 55 · Answer 4 · edited Jul 17 '17 at 08:49

55

I found the network drive was the performance problem. HOME was pointing to a slow network share. I could not override HOMEDRIVE but that is not a problem from what I have seen.

Set the environment variable by right clicking your computer on the desktop --> properties --> Advanced system settings --> Environment Variables Add to User variables section

HOME=%USERPROFILE%

edited Jul 17 '17 at 08:49

Stefan van den Akker

6,661
7
48
63

answered Jan 07 '15 at 22:34

MichaelK

559
4
2

6

This worked. For everyone that has the network problem this is the real solution. You don't have to edit any config file just make HOME point where it should. – Carlos Calla Feb 26 '16 at 15:21
2

Defining Env User Var HOME as %USERPROFILE% didn't work. I defined SYSTEM VAR : HOME=C:\Users\myUserName – colin_froggatt May 10 '16 at 15:34
Worked for me! Thanks. I did something like @colin_froggatt but in User Environment variables instead, setting HOME=C:\Users\myUserName – Ð.. May 01 '19 at 14:06
Working with Windows 10 in 2020 the HOME variable was unset, giving it a default value recovered my previously horrible git performance on 2.28. – glenatron Sep 21 '20 at 10:11
This worked for me. Thank you for your help! Windows 10 – Paul Wang Sep 24 '20 at 02:39
This worked like a charm for me, the easiest and the best solution I'd say. – Tech Sawy Feb 25 '22 at 09:04

score 29 · Answer 5 · edited Sep 13 '18 at 20:13

29

In an extension to Chris Dolan's answer, I used the following alternative PS1 setting. Simply add the code fragment to your ~/.profile (on Windows 7: C:/Users/USERNAME/.profile).

fast_git_ps1 ()
{
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [\1] / p')"
}

PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

This retains the benefit of a colored shell and display of the current branch name (if in a Git repository), but it is significantly faster on my machine, from ~0.75 s to 0.1 s.

This is based on this blog post.

edited Sep 13 '18 at 20:13

Peter Mortensen

30,738
21
105
131

answered Nov 20 '12 at 15:53

Wilbert

7,251
6
51
91

1

Great answer. However I've decided to redefine '__git_ps1()' in my ~/.bashrc, and just print empty string. It speeds up all the Bash commands. – ajukraine Jun 09 '13 at 18:47
I'm a git beginner, I'd like to know what the difference between this fast_git_ps1 and the original pretty complicated __git_ps1 is. I get the idea that this will work for most "normal" cases, but what's normal and where will this fail? – Sundar R Aug 01 '13 at 09:32
I am not aware of cases where it will fail. I did use the __git_ps1 before, but noticed the performance issues, so I tinkered around trying to make git do less work to extract the displayed information. – Wilbert Aug 05 '13 at 08:30
3

The original `__git_ps1` includes status information, not just the branch name. For example, if you're in a detached head state, in the git dir, in a bare repo, in the middle of cherry picking or rebasing or merging... This will be faster, but there may be occasions where you would miss this extra info, especially as a Git beginner. – Drew Noakes Feb 19 '15 at 11:38

score 23 · Answer 6 · edited Sep 13 '18 at 20:25

While your problem might be network-based, I've personally sped up my local git status calls tenfold (7+ seconds down to 700 ms) by doing two modifications. This is on a 700 MB repository with 21,000 files and excessive numbers of large binary files.

One is enabling parallel index preloads. From a command prompt:

git config core.preloadindex true
This changed time git status from 7 seconds to 2.5 seconds.

Update!

The following is no longer necessary. A patch has fixed this as of mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
However, you must enable the fix by typing
git config core.fscache true

I also disabled the UAC and the "luafv" driver (reboot required). This disables a driver in Windows Vista, 7 and 8 that redirects programs trying to write to system locations and instead redirects those accesses to a user directory.

To see a discussion on how this affects Git performance, read here: https://code.google.com/p/msysgit/issues/detail?id=320

To disable this driver, in regedit, change the "start" key at HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv to 4 to disable the driver. Then, put UAC to its lowest setting, "never notify".

If the disabling of this driver makes you wary (it should), an alternative is running on a drive (or partition) different than your system partition. Apparently the driver only runs on file access on the system partition. I have a second hard drive and see identical results when run with this registry modification on my C drive as I do without it on the D drive.

This change takes time git status from 2.5 seconds down to 0.7 seconds.

You also might want to follow https://github.com/msysgit/git/pull/94 and https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b to check out what additional work is underway for speed issues in Windows.

this only puts to light, yet again, idiotics and meandrous Microsoft solutions, to problems solved in Unix in a simple and elegant way in 1968. How much production effort, time and money has been wasted by Microsoft's bloat and lack of refactoring/flexiblity/audacity worldwide ? — v.oddou, Aug 05 '15 at 02:49
enabled by default in git 2.1 https://stackoverflow.com/a/24045966/4854931 — Alex78191, Jun 22 '17 at 10:20

score 21 · Accepted Answer · edited Jul 11 '17 at 08:48

21

It appears that completely uninstalling Git, restarting (the classic Windows cure), and reinstalling Git was the cure. I also wiped out all bash config files which were left over (they were manually created). Everything is fast again.

If for some reason reinstalling isn't possible (or desirable), then I would definitely try changing the PS1 variable referenced in Chris Dolan's answer; it resulted in significant speedups in certain operations.

edited Jul 11 '17 at 08:48

Liam

27,717
28
128
190

answered Dec 22 '10 at 04:37

Gemini14

6,246
4
28
32

4

Reinstalling without restart did not work, uninstall-restart-install worked. Thanks! It would be nice to know why and how bash got so slow, though. – Gauthier May 05 '11 at 06:46
Re-installing with reboot in-between made no difference for me. – RyanW Sep 12 '11 at 02:28
@RyanW I'm afraid I can't help beyond the solution above that worked for me, but since this issue doesn't seem to be permanently fixed yet, you might want to get in touch with msysgit's maintainers and see if they can figure out the cause of this issue. – Gemini14 Sep 12 '11 at 02:46
Did you happen to use `__git_ps1` before the reinstallation? – Tobias Kienzler Nov 16 '12 at 08:33
Nope (didn't even know it existed), although the standard MS Git installation seems to do this automatically from what I understand about `__git_ps1`. – Gemini14 Nov 21 '12 at 08:50
I had upgraded from msysgit v1.7.something to v1.8.1.2, but it was still going slow... uninstall, restart, install did the trick, thanks! – Herr Grumps Feb 25 '13 at 12:55
3

Which bash config files did you wipe out exactly? – Scott Mar 11 '14 at 02:45
I confirm this. Uninstall git, reboot your system, install git. This worked for me. Gitbash now works superfast. – Andrzej Rehmann Mar 01 '15 at 18:52
5

This is not the solution to the answer. When you uninstalled and reinstalled some config file might have changed, those changes are the answer. If you only say that reinstalling is the solution it is wrong. Other people may uninstall and reinstall and config files might be the same and that's why it won't work for everyone. – Carlos Calla Aug 18 '15 at 16:44

score 9 · Answer 8 · edited Sep 12 '18 at 08:46

9

I solved my slow Git problem on Windows 7 x64 by starting cmd.exe with "Run as administrator".

edited Sep 12 '18 at 08:46

Peter Mortensen

30,738
21
105
131

answered Oct 28 '11 at 01:04

Chris Pawlukowsky

141
1
2

10

The question talks about git bash. – manojlds Oct 28 '11 at 01:09
2

You can run git bash as administrator; which may seem to indicate an UAC problem – krosenvold Nov 04 '13 at 08:47
4

Wow, huge speed improvement running git bash as administrator – Evil E Feb 09 '14 at 05:20
I am not sure why this answer has just 6 up votes. I think this answer solved the problem completely. There is a huge speed improvement. – Codex Jul 11 '18 at 05:50
3

@vinoth10 Well, there's the issue with, you know, running as administrator. Which for many reasons is a bad idea, and for many corporate use cases is not an option at all. Solving a performance problem by elevating the user is a horrible solution. – JHH Apr 27 '19 at 21:47
Besides the important remark of @JHH this does not help in my case either. – bjhend Jun 24 '19 at 13:25

score 8 · Answer 9 · edited Sep 13 '18 at 20:33

You might also gain a very subsquent performance boost by changing the following Git configuration:

git config --global status.submoduleSummary false

When running the simple git status command on Window 7 x64, it took my computer more than 30 seconds to run. After this option was defined, the command is immediate.

Activating Git's own tracing as explained in the following page helped me found the origin of the problem, which might differ in your installation: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

score 7 · Answer 10 · answered Aug 17 '13 at 10:49

7

I saw a decent improvement by setting core.preloadindex to true as recommended here.

answered Aug 17 '13 at 10:49

Andy

331
2
12

score 6 · Answer 11 · edited Sep 13 '18 at 20:17

6

As noted in Chris Dolan's and Wilbert's answers, PS1 slows you down.

Rather than completely disabling (as suggested by Dolan) or using the script offered by Wilbert, I use a "dumb PS1" that is much faster.

It uses (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null:

PS1='\033[33m\]\w \n\[\033[32m\]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) \[\033[00m\]# '

On my Cygwin, this is faster than Wilbert's "fast_Git_PS1" answer - 200 ms vs. 400 ms, so it shaves off a bit of your prompt sluggishness.

It isn't as sophisticated as __git_ps1 - for example it doesn't change the prompt when you cd into the .git directory, etc. but for normal everyday use it's good enough and fast.

This was tested on Git 1.7.9 (Cygwin, but it should work on any platform).

edited Sep 13 '18 at 20:17

Peter Mortensen

30,738
21
105
131

answered Oct 21 '13 at 16:46

sinelaw

16,205
3
49
80

You can also use the `--short` option to not print `refs/heads/` – friederbluemle Oct 22 '13 at 23:39
@friederbluemle, which version of git are you using? Mine (1.7.9) doesn't offer `--short` for the `symbolic-ref` command. – sinelaw Oct 23 '13 at 14:02
Updated to not print errors when outside any git repo, and to work for detached HEADs – sinelaw Oct 23 '13 at 14:23
I'm using 1.8.4 (msysgit) – friederbluemle Oct 24 '13 at 06:31

score 6 · Answer 12 · edited Sep 13 '18 at 20:34

6

In addition to these other answers, I've sped up projects with multiple submodules by using parallel submodule fetching (since Git 2.8 in early 2016).

This can be done with git fetch --recurse-submodules -j8 and set with git config --global submodule.fetchJobs 8, or however many cores you have/want to use.

edited Sep 13 '18 at 20:34

Peter Mortensen

30,738
21
105
131

answered Jun 15 '18 at 15:27

codehearts

483
1
9
16

score 5 · Answer 13 · edited Sep 13 '18 at 20:30

I was having the same problem, in both Git Bash and Git GUI. Both programs use to run nicely, but then they randomly slowed down to a crawl, and I couldn't figure out why.

As it turns out, it was Avast. Avast has caused odd things to happen to various programs (including programs I write), so I disabled it for a second, and sure enough, Bash now runs as fast as it does on Linux. I just added the Git program files folder (C:\Program Files\Git) to the Avast exclusion list, and now it runs as fast as it does on Linux.

And yes, I realize the antivirus software was not the issue in the original post, but I'll just put this here in case it's useful to someone.

score 5 · Answer 14 · answered May 12 '18 at 11:03

5

Only turning off AMD Radeon Graphics (or Intel Graphics) in Device Manager helped me.

I found the answer here: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=

answered May 12 '18 at 11:03

Alexander Trofimov

602
9
10

score 4 · Answer 15 · edited Sep 13 '18 at 20:30

4

In my case, the Git Bash shortcut was set to Start in:%HOMEDRIVE%%HOMEPATH% (you can check this by right clicking Git Bash and selecting properties). This was the network drive.

The solution is to make it point to %HOME%. If you do not have it, you can set it up in the environment variables and now Git Bash should be lightning fast.

edited Sep 13 '18 at 20:30

Peter Mortensen

30,738
21
105
131

answered May 12 '16 at 09:00

mahacoder

895
3
14
29

I think this answer should have more votes. I came here to post this same recommendation, but saw you already beat me to it lol. – Jon Oct 25 '19 at 16:46

score 4 · Answer 16 · edited Jun 22 '18 at 14:16

Combined answers:

Wilbert's - what info to include in PS1
sinelaw's - (<branch_name>) or (<sha>)

# https://unix.stackexchange.com/questions/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt
# \033 is the same as \e
# 0;32 is the same as 32
CYAN="$(echo -e "\e[1;36m")"
GREEN="$(echo -e "\e[32m")"
YELLOW="$(echo -e "\e[33m")"
RESET="$(echo -e "\e[0m")"

# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackoverflow.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382
fast_git_ps1 ()
{
    git -C . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))"
}

# you need \] at the end for colors
# Don't set \[ at the beginning or ctrl+up for history will work strangely
PS1='${GREEN}\u@\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

Result:

@keinabel At this moment I would look at `core.commitGraph=true` from https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/ and other from https://blogs.msdn.microsoft.com/devops/tag/git/ — rofrol, Sep 10 '18 at 14:43

score 2 · Answer 17 · edited Sep 13 '18 at 20:15

I've encountered the same problem running Git for Windows (msysgit) on Windows 7 x64 as a limited user account for quite some time.

From what I've read here and other places, the common theme seems to be the lack of administrative privileges and/or UAC. Since UAC is off on my system, the explanation that it is trying to write/delete something in the program files directory makes the most sense to me.

In any case, I've resolved my problem by installing the portable version of Git 1.8 with zipinstaller. Note that I had to unpack the .7z distribution file and repack it as a ZIP file in order for zipinstaller to work. I also had to manually add that directory to my system path.

The performance is fine now. Even though it is installed in the Program Files (x86) directory, which I don't have permissions for as a limited user, it doesn't seem to suffer from the same problem.

I ascribe this either to the fact that the portable version is a bit more conservative in where it writes/deletes files, which is probably the case, or to the upgrade from 1.7 to 1.8. I'm not going to try to pin down which one is the reason, suffice to say it works much better now, including Bash.

Turning off UAC seems to solve the "big" part of the problem for us (multi-second delay). The ps1 hack did the rest. — krosenvold, Nov 04 '13 at 08:46
Same I'm on SSD, 32GB RAM and quad core i7 and none of the other answers helped, disabled UAC, restart and git commands are INSTANT — phil_lgr, Mar 08 '17 at 17:54

score 2 · Answer 18 · edited Sep 13 '18 at 20:32

2

In my case, it actually was Avast antivirus leading to Git Bash and even PowerShell becoming really slow.

I first tried disabling Avast for 10 minutes to see if it improved the speed and it did. Afterwards, I added the entire Git Bash installation directory as an exception in Avast, for Read, Write and Execute. In my case that was C:\Program Files\Git\*.

edited Sep 13 '18 at 20:32

Peter Mortensen

30,738
21
105
131

answered Jul 21 '16 at 23:09

Mastergalen

4,289
3
31
35

I want to confirm this tips. Exclude git from Avast really make thing faster. I see git status without waiting anymore. Win 7 x64 – fajarhac Apr 11 '17 at 05:08
Antiviruses only interfere. – Alex78191 Jun 22 '17 at 10:34
1

Thanks, that was definitely a quick win! Disabled avast for 10 minutes, noticed an instant change in git performance (i.e. return to normal execution times). – Marcello Romani Nov 24 '17 at 11:44
This solution worked for me. McAfee + Windows 10 Ent. – FractalSpace Jan 28 '19 at 17:00

Eugene Pakhomov · Answer 19 · 2018-01-05T07:36:26.997

1

If you use Git from cmd, try running it from Git Bash. In cmd, git.exe is actually a wrapper that sets up the correct environment every time you start it, and only then launches the real git.exe. It can take up to twice as much time as it's required to just do what you want. And Git Bash sets up the environment only when it starts.

edited Jan 05 '18 at 07:36

answered Jul 19 '16 at 08:57

Eugene Pakhomov

9,309
3
27
53

score 1 · Answer 20 · edited Jan 26 '23 at 22:14

Nothing of the above was able to help me. In my scenario the issue was showing itself like this:

Any ls -l command was slow (was taking about 3 seconds to execute)
Any subsequent ls -l command was executed instantly, but only if within 45 seconds from the previous ls command.

When it came to debugging with Process Monitor it was found that before every command there was a DNS request.

So as soon as I disabled my firewall (Comodo in my case) and let the command execute the issue is gone. And it is not returning back when the firewall was switched back on. With the earliest opportunity I'll update this response with more details about what process was doing a blocking DNS request and what was the target.

score 1 · Answer 21 · answered Jan 21 '21 at 09:14

I've had similar situation and my problem was related to Active Directory and sitting behind vpn.

Found this gold after working like that for half a year: http://bjg.io/guide/cygwin-ad/

All you basicaly need is to disable db in /etc/nsswitch.conf (you can find it in your git directory) from passwd and group section, so the file looks like:

# Begin /etc/nsswitch.conf
passwd: files
group: files
db_enum: cache builtin
db_home: cygwin desc
db_shell: cygwin desc
db_gecos: cygwin desc
# End /etc/nsswitch.conf

and then update your local password and group settings once:

$ mkpasswd -l -c > /etc/passwd
$ mkgroup -l -c > /etc/group

score 0 · Answer 22 · edited Sep 13 '18 at 20:31

0

A co-worker of mine had troubles with Git on Windows (7) git status checkout and add were fast, but git commit took ages.

We are still trying to find the root cause of this, but cloning the repository into a new folder fixed his problem.

edited Sep 13 '18 at 20:31

Peter Mortensen

30,738
21
105
131

answered May 24 '16 at 12:37

mrcl

338
5
9

score 0 · Answer 23 · edited Nov 23 '18 at 18:21

0

As many said, this is due to stash being a shell script on Windows, but since Git 2.18.0 the Windows installer has an option for an experimental feature of a much faster (~90%) built-in version of stash - https://github.com/git-for-windows/build-extra/pull/203.

edited Nov 23 '18 at 18:21

Peter Mortensen

30,738
21
105
131

answered Oct 22 '18 at 21:20

bergmeister

949
2
10
16

That helps with `stash`, but yours is the first post mentioning `stash` specifically. Does it affect other Git operations? – Michael Nov 29 '18 at 14:47
As far as I understand, no. Tthere are 2 experimental features in preview that allow to have `stash` and/or `rebase` using a native executable for better performance but with anything in preview there is always a small chance that there might be a small side-effect. – bergmeister Nov 29 '18 at 18:28
1

P.S. This feature went out of preview in v 2.19.1, therefore you do not get the option for it any more – bergmeister Nov 29 '18 at 18:36

score 0 · Answer 24 · 2023-05-18T02:23:43.323

I found out two helpful method to diagnose, from git repo wiki: https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues

Basically, adding set -x to the top of <git install home>/etc/profile, will echo actual shell commands executed. This way you can find out which command is causing prompt delay.

But in my case, it was mainly those network operations. I prepended GIT_TRACE=1 to my git command, so that it prints out sub git commands it was executing.

In my case, I found out git-credential-manager get got executed multiple times, and each call waits over a few seconds. So after googling it, I tried git config --system --unset credential.helper in admin mode. Sourcetree is fast now, though I need to reenter credential each time in git bash.

Some suspect it was caused by antivirus, but I can't verify it now. https://github.com/Microsoft/Git-Credential-Manager-for-Windows/issues/786

score -1 · Answer 25 · edited Sep 13 '18 at 20:28

I also had issue with git PS1 slowness, although for a long time I was thinking it's a database size problem (big repository) and was trying various git gc tricks, and were looking for other reasons, just like you. However, in my case, the problem was this line:

function ps1_gitify
{
   status=$(git status 2>/dev/null )      # <--------------------
   if [[ $status =~ "fatal: Not a git repository" ]]
   then
       echo ""
   else
       echo "$(ps1_git_branch_name)  $(ps1_git_get_sha)"
  fi
}

Doing the git status for every command line status line was slow. Ouch. It was something I wrote by hand. I saw that was a problem when I tried the

export PS1='$'

like mentioned in one answer here. The command line was lightning fast.

Now I'm using this:

function we_are_in_git_work_tree
{
    git rev-parse --is-inside-work-tree &> /dev/null
}

function ps1_gitify
{
    if ! we_are_in_git_work_tree
    then
    ...

From the Stack Overflow post PS1 line with git current branch and colors and it works fine. Again have a fast Git command line.

So your problem was caused by a script you had written? Maybe that script is not so likely to be the cause, for other users who search for the same problem... — Jolta, Mar 17 '16 at 15:29
Take a look at the OP question - he mentioned lots of things he had checked, and still it wasn't it. The same was with me. So here I added another thing to be checked when nothing helps. And it's not this specific script that I've written that is important, but a concept - look at your PS1. — Koshmaar, Mar 19 '16 at 10:32

Git Bash is extremely slow on Windows 7 x64

25 Answers25

Linked