Disable the Git source control add-in in VS2013, permanently

Update: 27th June 2014

The registry hack stopped working for me for some reason, possibly after I installed VS2013 Update 2. In the little movie world in my head (where I have a speaking part and an end credit instead of being a CG head in a crowd, or possibly a Class 5 droid) there’s a minor war going on between me and the Microsoft guys who wrote this oddly insistent Source Control Provider. I found a way to disable it; they found a way to re-enable it. So I’ve escalated my efforts. Screw those guys.

You can now install my first ever published Visual Studio extension, NoGit, from the Extensions dialog in Visual Studio, or download it from the Visual Studio Gallery. Every time you load a Solution, it checks to see if the current Source Control Provider is Microsoft’s Git provider, and if it is, it deactivates it.

The original text of this post has been preserved for historical context.

This has been driving me nuts. I don’t know what particular combination of things contributes to it, but the Git source control provider that’s built into Visual Studio 2013 just hangs the whole system. I change it to “None” in Tools/Options, but every now and then it comes back. I never, ever use it – CLI all the way – so its very existence was offending me to the core.

Now, I think I’ve found out how to kill it, via that old nasty-hack-atron, regedit.exe.

<DISCLAIMER>

If you do this and it kills Visual Studio, or Windows, or your PC, or a kitten, I will not accept responsibility. I hate the VS Git plug-in enough to take this chance, but it is a chance. It seems to have worked for now, but your mileage may vary.

</DISCLAIMER>

Note: I have Visual Studio 2013 Ultimate Edition. It is possible that some of these keys may be different for other editions.

Right, close all instances of VS2013, open up regedit and navigate to the following entry:

HKEY_CURRENT_USER
|-Software
|-|-Microsoft
|-|-|-VisualStudio
|-|-|-|-12.0_Config
|-|-|-|-|-SourceControlProviders

There should be three keys below that node (unless you’ve installed other providers, I guess, you dirty Subversion user, you). On my machine, the Git provider had this GUID:

{11B8E6D7-C08B-4385-B321-321078CDD1F8}

I’m guessing that’ll be the same on yours, but click on it and check the value of the (Default) key within it. Should be GitSccProvider. If it’s not, find the one that is.

Got it?

Good. Now delete that whole node.

Now, just for good measure, go back up to the root of the regedit tree and do a search on that GUID – I left off the braces. You should find it in a couple more places: an “AutoloadPackages” node and also in the HKEY_USERS section. Delete all of them.

Eventually, the only place you’ll find it is in a section which seems to hold the last thing you looked at in regedit, which is deliciously recursive.

Here’s a shot of my Visual Studio 2013 Ultimate Edition Source Control options after I did this:

image

If it comes back again, I’ll delete this post. And probably become a hipster Hack programmer using Vim on a Linux box (with dual-boot to Windows for the sole purpose of playing Titanfall).

Comments

  1. Its been driving me nuts as well, seems to have improved a bit over time however do I go for the regedit hack it or not!

  2. Franck Terray says:

    Interesting to see the same registry hack in VS2013 as I use in VS2010. I had to use the same technic to remove our old “Visual Source Safe” plug-in taking over our “new” TFS plug-in. Otherwise, I couldn’t switch source control server back to TFS.

  3. JPHellemons says:

    How did you find out that the git plugin made your system hang? I also have strange VS2013 hangs, but mine seem to be related to mvc projects with iis express somehow. Maybe also in combination with a git plugin, but I do not know that for sure. So how did you narrowed it down to the git plugin?

    • I can’t remember, I think I was complaining on Twitter and somebody suggested to set Source Control to None. It’s possible that it’s a problem with interaction between the Git plug-in and something else – I have a lot of extensions installed. But the Git SCC provider is the one I don’t need at all, so it has to go. :)

  4. Michael Spiering says:

    Thanks for this. I wanted to disable the MS git provider and opt for CLI, because I work with a combination of git/tfs (git local, tfs for team) and whenever Visual Studio saw the .git directory, it forced me in the direction of git. Now I can put my .git directory back, and tfs works. When I open the project, I get a warning that the “project or solution that you opened requires a source control plugin that is unavailable …”, but once past that dialog, tfs source control bindings are at least there. I don’t know why anyone thought “there whether you want it or not” would be an improvement over an extension that works well for people who want it.

  5. Thanks for writing this up. I’d had some odd problems with VS when using git form command line, these seem to have disappeared after following these instructions. Now get an annoying popup saying the source provider isn’t available when opening a solution file, as others are still use the VS/git integration, so the bindings are still in the solution. Don’t suppose you have a work round for this?

    • I think the source control settings for the project are in the suo file, which shouldn’t be under source control. Try getting rid of that, see if it helps.

  6. I’ve found that all instances of Visual Studio open would consume all of my CPU for 3-4 minutes each time I updated a file in or added a file, etc, to a large git repo that VS was aware of. This was extremely annoying because compiling the project itself causes Visual Studio to churn along with 100% CPU usage across three instances for 3 minutes causing compiles to be slower and debugging the program to be horrid

  7. The NoGit extension doesn’t seem to work for me in VS2013 with update 2, though the registry hack used to. I might be doing something wrong but when I open my .sln it always flips to the Git view in Team Explorer and if I connect back to my TFS project it closes the solution. Any ideas what might be wrong? If the source code for the extension available somewhere I would be happy to try to debug myself too.

      • With the source I was able to get it working, but it’s a really weird workflow. First, I cloned the repository, opened it in Visual Studio and debugged it. It did not appear to work while I was debugging.

        However, if I open another .sln under git source control without closing Visual Studio it works.

        I have no idea why. Looking at the code, everything seems like it should work but the only way it works on my machine is if I debug the extension first before opening a real solution.

        Anyway, thanks for putting the code up. It’s working well enough for me now.

  8. Since installing update 2 and trying the nogit extension, the git bits still appear to be churning away and melting my CPU. NoGit does appear to be working. trying to view source control history and such properly shows that it’s not using git, but it has reverted to churning away at my CPU causing Visual Studio to become unusuable for minutes at a time

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,015 other followers

%d bloggers like this: