82

I love git and use it on OS X pretty much constantly at home. At work, we use svn on Windows, but want to migrate to git as soon as the tools have fully matured (not just TortoiseGit, but also something akin the really nice Visual Studio integration provided by VisualSVN). But I digress...

I recently installed msysgit on my Windows 7 machine, and when using the included version of bash, it is horrendously slow. And not just the git operations; clear takes about five seconds. AAAAH!

Has anyone experienced a similar issue?

Edit: It appears that msysgit is not playing nicely with UAC and might just be a tiny design oversight resulting from developing on XP or running Vista or 7 with UAC disabled; starting Git Bash using Run as administrator results in the lightning speed I see with OS X (or on 7 after starting Git Bash w/o a network connection - see @Gauthier answer).

Edit 2: AH HA! See my answer.

Kevin L.
  • 4,548
  • 7
  • 39
  • 54
  • Not 5 seconds slow, no. It will be slower, but faster than the Cygwin version. – Yann Ramin May 14 '10 at 16:32
  • @theatrus: I actually used a stopwatch just now. The average was 3.8 seconds. So you're correct, but something is still deeply wrong. – Kevin L. May 14 '10 at 17:41
  • One other msysgit slowdown is an old version of OpenSSH is documented here http://darrell.mozingo.net/2011/09/29/painfully-slow-clone-speeds-with-msysgit-gitextensions/ – JodaStephen Jul 13 '13 at 11:53
  • 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:48
  • 1
    possible duplicate of [Git/Bash is extremely slow in Windows 7 x64](http://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64) – Joshua Taylor Sep 22 '15 at 02:20
  • So I am not the only one - in my case disabling avast helped though - google led me here from: https://www.google.be/search?safe=off&hl=en&q=avast+antivirus+git+slow&spell=1&sa=X – Mr_and_Mrs_D Oct 22 '15 at 10:54
  • This also happens in Linux Bash Shell on Windows 10. – zwcloud Jan 05 '17 at 13:09

19 Answers19

55

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/

shoelzer
  • 10,648
  • 2
  • 28
  • 49
  • This should be now the accepted answer. Works like a charm! – krlmlr Jul 17 '14 at 06:24
  • 8
    This does not work for me. My git bash is still 1-2 seconds delay after I give a command. – JaskeyLam Jul 31 '14 at 03:17
  • Worked like a charm for me; brought my git status on a large repo down from 13sec to 0.7sec – noelob Dec 05 '14 at 23:32
  • 2
    `git config --global core.fscache true` did nothing for me; however, `git config core.fscache true` did the trick. According to [this](https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow), it's because core.fscache is a per repo setting. – David Merriman Jan 29 '15 at 22:12
  • 2
    @DavidMerriman The "per repo" comment is simply stating that you *can* change this setting on individual repos. (Which is true of all settings, so I don't know why it's mentioned at all.) The comment does not mean that `fscache` *only* works as a per repo setting. Global settings apply to all repos on a machine unless overridden by per repo settings. – shoelzer Jan 30 '15 at 15:21
37

The solution for slowness on Vista or 7 appears to be running Git Bash using Run as administrator (or disabling UAC for the Git Bash shortcut...or disabling UAC entirely). The difference is night and day and using git on 7 is awesome again.

This appears to be related to a known issue and, as I speculated, XP as a development environment for msysgit is partially responsible.

Kevin L.
  • 4,548
  • 7
  • 39
  • 54
  • Nice hint (even if it was unintentional :)). Running "git svn clone" in Windows 2008 R2 with 1.7.4 was terribly slow for me (there are 5000+ commits in SVN and it took weeks just to get the half of it)... You gave me the idea to try it in its "native" environment, on XP, and it's actually very fast. Thanks! – bdrajer Aug 12 '11 at 18:02
  • 1
    I've disabled UAC and tried running at administrator, and still every command I enter into Git Bash takes about 5 seconds to run (even just `ls` in a practically empty directory) – Robin Winslow Sep 07 '12 at 09:23
  • 4
    The answer in this question worked for me instead: http://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64 – Robin Winslow Sep 07 '12 at 09:50
  • Moving repos to a non-system partition also showed large performance increases for my team, and prevented the random "unable to create file" issues on checkout. – Laurence Jul 16 '13 at 12:42
  • This makes it snappier but pushing / pulling takes forever. This is probably due to a bug. See link in original question (reproduced here): http://code.google.com/p/msysgit/issues/detail?id=320 – imanuelcostigan Sep 12 '13 at 03:48
  • I have UAC turned on and I don't run Git Bash as administrator - but console is still very sloow on Windows 7. Same version of msysgit performs much better on WinServer 2012 R2, though. – chester89 Dec 20 '13 at 11:56
  • 1
    i tried a lot of solutions.. this one (running as administrator) finally worked for me.. now my git is lightning fast once again.. thanks.. :) – AweSIM Oct 26 '15 at 07:29
  • This is still an issue in Windows 10 for me and this is still the solution that has always worked. – caesay May 29 '17 at 01:14
14

For me the issue was the use __git_ps1 in the shell prompt - I guess due to slow disk access in msysgit.

Solution was to remove $(__git_ps1) from the PS1=... lines in /etc/profile

quick test if this solution applies: in a git shell, type export PS1='$ ' and check the speed of your operations.

chrisxxyy
  • 159
  • 1
  • 4
  • Thanks! This turned out to be my problem on Windows XP. See http://stackoverflow.com/q/5851611/200688 – AndyL May 01 '11 at 23:12
  • 2
    You can probably let `__git_ps1` active, if you disable the SHOWDIRTYSTATE and/or SHOWUNTRACKEDFILES settings, see http://stackoverflow.com/a/4203968/321973 – Tobias Kienzler Nov 16 '12 at 08:32
  • This was all it took for me on Windows 7. Particularly lucky as this machine is locked down with no Admin privs! – Air Feb 10 '14 at 16:52
12

Tried just about all tips here (including the one from my other answer) on a new machine, but they didn't work, Git still slow as hell.

Then I had a look at the virusscanning software (that was pre-installed) : I disabled McAfee Security Center's realtime scanning, and presto: git is blazing fast now! Time needed for "git svn rebase" dropped from 30s to 5s (!).

I hope this is helpful to other people still having issues with slow Git on Windows, I lost hours figuring this out.

Tom De Leu
  • 8,144
  • 4
  • 31
  • 30
  • 4
    My Git Bash also starts slow before, after I add the whole path of git installation to exclusion path of Avast! Anti-Virus Suite, git bash starts lower than 0.5s – zhxchen17 Mar 31 '15 at 17:26
  • **This** was the answer for me!! I use AVG Free. I just disabled it for 10 minutes, suddenly the veeerrryyyy sluggish bash is lightning fast. – Mörre Jun 18 '15 at 15:37
  • For those using Windows Defender, you can have it exclude a folder or process. See https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-defender-antivirus – Ehtesh Choudhury May 31 '18 at 18:47
9

Alas 'Run as Administrator' didn't work for me - but as Kevin L found, disconnecting the network adapter, launching git bash, then reconnecting worked fine. So I wrapped this up in a batch script and put a shortcut to it in my Start menu, flagged to run as admin:

netsh interface set interface "Local Area Connection" DISABLED
cd "%USERPROFILE%\Documents\Visual Studio 2010\Projects"
start cmd /c ""C:\Program Files\Git\bin\sh.exe" --login -i"
netsh interface set interface "Local Area Connection" ENABLED

Works a treat as long as I remember my network gets momentarily cut off.

(Win 7 Professional SP1, Git version 1.7.8-preview20111206)

Daniel Hume
  • 437
  • 4
  • 9
4

A colleague of mine had this behaviour whenever Outlook was running. Trying killing outlook and test again.

You could also try to test:

  • without connection to any network,
  • without antivirus running,
  • without any other program running.
Gauthier
  • 40,309
  • 11
  • 63
  • 97
  • 3
    Neither Outlook nor antivirus seem have any effect, but if I disable my network connection then start git, it is lightning (read: "Unix") fast, even after I reconnect. Interesting... – Kevin L. May 26 '10 at 15:35
  • Yep. And git bash remains fast (until I close it and open another instance). – Kevin L. May 27 '10 at 21:25
  • 2
    Network connection worked for me too. I wonder what it has to do with network connection. And strangely it works perfectly fine at my home network but refuses to work on my office network. – Sarath Jul 20 '11 at 07:02
  • This fixed my issue on Windows 7 Professional 64-bit on a brand new iMac. Cheers! – longda Nov 01 '11 at 22:54
  • +1 antivirus as suggested was the cause on my particular system. windows 7 x64 ultimate. UAC (mentioned elsewhere) made no difference sadly. thanks to everyone –  Dec 10 '11 at 00:38
3

We found that, when running on certain user accounts, separate git.exe instances blocked on a call to WaitForSingleObject(), so only a single git.exe operation could effectively run at once. Changing the user account worked around this issue.

Details here: https://stackoverflow.com/a/13054022

Community
  • 1
  • 1
Matthew Skelton
  • 2,220
  • 21
  • 21
3

I have MacAffee and telling it to exclude the .git directory and all subdirectories from real-time-scanning addressed the performance problem.

Alex Brown
  • 41,819
  • 10
  • 94
  • 108
1

If turning off UAC doesn't improve performance, try turning off the luafv driver. This worked for me after trying almost everything on this page and the couple of similar questions. Git has gone from unusably slow to pretty decent.

Open 'regedit' and find the registry key 

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/luafv

Change the value of Start from 2 to 4.

I found the details on how to disable luafv here. Note that I personally have no idea what luafv is or does. That page gives various warnings about bad things that might happen if you turn it off, which you should probably take seriously.

EDIT: The comment below pointed out I got this the wrong way round (the link has it the right way round). It is fixed now. Sorry to the people whose registries I trashed :)

jwg
  • 5,547
  • 3
  • 43
  • 57
1

An alternative to messing with the Windows 7 UAC may be to install mysysgit outside of your Program Files folder. For example instead of "C:\Program Files (x86)\Git", try installing in "C:\git"

I tried fiddling with 'Run as admin' and UAC controls to no avail, but gave up and started over a fresh install. I was getting about 15KiB/s max before, but is now over 60kiB/s.

Frank Yin
  • 1,920
  • 1
  • 17
  • 12
1

I've just been troubleshooting this for a while and had a hard time pinpointing the source of the problem. In the end I found two things that had a dramatic impact:

  • Turning off the Windows Search service. This had a dramatic effect on performance.
  • Closing Git Extensions. Having the Git Extensions Browse window open in the background caused Cygwin git command execution times to increase by a seemingly random factor of up to around 10.
bjos
  • 11
  • 1
1

As found in this issue, running with UAC virtualization turned off (it's not needed to disable UAC entirely) makes a big difference.

This post explains how to turn it off (see the bottom of the post, just one registry setting).

On one (large) SVN repo I'm connecting to, making just the above change dropped the time needed for "git svn rebase" from 15s to 5s, a factor 3 improvement.

Tom De Leu
  • 8,144
  • 4
  • 31
  • 30
0

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

Binary Phile
  • 2,538
  • 16
  • 16
0

You might want to try uninstalling msysgit, restart windows, install latest version of msysgit. It seemed to do the trick for me. I found this suggestion here:

https://stackoverflow.com/a/4506192/1413941

EDIT

PS I already had UAC disabled before I ran into slow Git issues, so I don't know if disabling UAC is required or not to get Git going fast.

Community
  • 1
  • 1
Herr Grumps
  • 2,044
  • 1
  • 19
  • 10
0

The issue here might be the bash-completion if that's enabled, which is quite a bit slower on Windows than Linux.

Try setting the PS1-variable to something simple like "$ ", and see if this speeds things up. If it does, be aware that there's been some optimizations to the bash-completion in recent-ish git-versions. Perhaps you need to upgrade.

kusma
  • 6,516
  • 2
  • 22
  • 26
  • 1
    I'm running the absolute bleeding-edge newest version (see my comments on VonC's answer, above). But I'll give this a shot. – Kevin L. May 27 '10 at 21:27
  • 1.7.0.2 isn't necessarily the bleeding-edge in this context. The optimizations I'm talking about have happened in upstream-git. I'm not sure if they were in for the 1.7.0.2 release of Git for Windows or not. – kusma May 28 '10 at 12:17
0

The best solution is to run as administrator, as pointed out. However another option to make git status fast, at least, is trustctime = false. Before that git status took about 30 seconds and after that it is the same amount that is shown in the output - It took X seconds to...

TS'
  • 113
  • 1
  • 13
0

You might also gain an important 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, 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

Olivier
  • 617
  • 1
  • 7
  • 9
0

This worked for me. Don't expect it will be a one size fits all solution.

Check the $HOME environment variable in bash and windows. If it points to a user account, check the user's windows profile/permissions. Change either the user account or the $HOME accordingly.

Deepak
  • 1
-4

It's probably a matter of the prompt which analyzes your Git repository. You can test by doing "clear" somewhere outside of a Git repository. And you can accelerate it by either patching git-completion.bash or by playing tricks with core.filemode.

As for the Visual Studio integration: This is Open Source. It is unfair to expect others to work for you for free.

I also find it rather funny not to ask the question on the msysGit mailing list, but now I digress.

Dscho
  • 45
  • 1
  • 5
    Flaming on StackOverflow should not be tolerated. Please try to keep the discourse more civil – Phil Hord Jul 29 '10 at 13:17
  • 1
    It is funny. My comment was the _only_ comment with concrete technical information. The offer to assist in helping fix the issue is still open, you know? And of course I am quite upset that the issue was raised here, on stackoverflow, which I do not monitor, and which had to be pointed out by others to me. I would have preferred to hear about the issue directly. I don't know about you, but I find it unfair when the original project is not even notified of problems. – Dscho Jul 30 '10 at 09:35
  • Two years later, I agree. I was too harsh. Sorry, Dscho. The git developer mailing lists are really helpful. – Phil Hord Apr 04 '12 at 13:12
  • 2
    @Dscho, you should understand that people often post here first because they want to check that there is not some configuration or platform issue, which is not a bug in Git, causing their problem. – jwg Feb 14 '13 at 07:41