Fix – Microsoft Visual Studio 2017 – v15.7.4 can’t checkout / switch to some git branches

I could checkout Dev, but I could not checkout master, but after some time, I could checkout the branches master, Acc and Test but not Dev.

When clicking on another branch name, Visual Studio wouldn’t do anything:

After unchecking the checkbox: “Checkout branches asynchronously when possible (Experimental)”, the problem was fixed and I could checkout all branches again.

Fix: ECMDERR Failed to execute "git ls-remote –tags –heads git://", exit code of #128

When I wanted to install a bower package inside Microsoft Visual Studio 2015 update 1 (inside a corporate netwerok), I got the error:

ECMDERR Failed to execute "git ls-remote –tags –heads git://", exit code of #128


This solution:

Enter the following command on the commandline:

git config –global url."https://".insteadOf git://

Git 101


Git is a decentralized version control system as opposed to a centralized version control system, like TFS, SourceGear Vault, Subversion, Visual Source Safe etc.

A centralized version control system, has a single server that contains all the versioned files, including their history, and a number of clients that check out files form that central place.

A decentralized version control system (such as Git, Mercurial, Bazaar, Darcs etc.), mirrors the respository (including all history) to all clients.


Storing data

Every time you commit, or save the state of your project in Git, it basically takes a “picture” (also revered to as a snapshot) of what all your files look like at that moment and stores that snapshot. You can think of this snapshot as a copy of all files in your working folder (that are tracked).


Storing data efficiently

Git has several mechanisms to store data  efficiently:

  • Each file is zlib compressed before it is stored as a blob in the .git folder and refered to by a SHA-1 of its content.
  • If a file in a snapshot is not changed, the snapshot will not contain a copy of the file, just a pointer (SHA-1) to the file already in git.
  • Once in a while, git will comporess multiple blobs into a single packfile, to increase compression ratio.

By using these mechanisms Git does not have to store deltas at the file level, to be efficient on storage and fast will be extremely fast, when previous snapshots should be restored.



The snapshot will get an identifier associated with it (a SHA-1 of the snapshot content). A SHA-1 is a 40-character checksum string composed of hexadecimal characters (0–9 and a–f) that uniquely indentifies the contents of the snapshot.


Now there are serveral ways you can work with Git. This blog post describes the way, we use Git.


Clone remote respository and commit your first change

The following diagram describes the proces of cloning a remote Git repository and making you first change to it on a locale repository.





Fetch and merge changes from remote to local and push changes from local to remote

The following diagram describes the process of fetching and merging remote changes to a local repository and then pushing local changes back to the remote repository:






We use 3 long lived branches and short lived feature branches on the remote git repository:

  • master
    • all changes that should go in the product will eventualy be merged into master
    • all branches will be created from this branch
  • acceptance
    • when it is time to deploy the software to the acceptance servers, the code from master is pulled to the acceptance branch and a build of this acceptance branch will be deployed to the accepatance servers.
  • production
    • when it is time to deploy the software to the production servers, the code from the acceptance branch is pulled to the production branch and a build of this production branch will be deployed to the production servers.
    • when a bug is found in production, it is fixed on the production branch, then fetched and merged into the acceptance branch and then fetched and merged from the acceptance branch in to the master branch.
  • Feature branches
    • All development is done in feature branches.





Now this is not perfect, but you can add branches for QA, test or pre-prod, at will, but  maybe you don’t want a branch for each “software life cylce” step and just want to use branches foreach release, thats all up to you.

Convert SourceGear Vault Standard v3.1.9 to Git including all history

To convert files from a SoureGear Vault Standard v3.1.9 to Git including all history I went on a journey and in this blog post I will describe the journey steps.

Note: this blog post will probably contain unnecessary steps, but non the less it describes the steps how I successfully converted all files found in a SourceGear Vault Standard v3.1.9 server to Git, including all history.





  • The SourceGear Vault Standard v3.1.9 was installed on a Microsoft Windows 2003 32bit Server.
  • On the server was a Microsoft SQL Server 2005 32 bit installation.
  • During the upgrade I switched to a Windows 10 (64 bit) Hyper-V machine.
  • To prevent “multi user” sql connection problems, make sure you stop the vault service with a iisreset /stop, before installation.
  • All developers should checkin their files on the SourceGear Vault Standard v3.1.9 server.
  • Verify that no files are checked out with the Vault Standard v3.1.9 admin tool.
  • If you are using SQL Server 2005 make sure that the database sgvault is in SQL Server 2005 compatibility modus



Steps on the Microsoft Windows 2003 32bit Server


  • For the conversion, I added the SourceGear Vault Service IIS application pool user, to the local administrator group.
  • Our Vault Service connects to SQL Server by using windows authentication. I added the sgvaultuser, Network Service and the locale user that was executing the setups to the SQL Server sysadmin group for the conversion.



Steps on the Microsoft Windows 10 64bit Hyper-V virutal machine

The following steps were executed on an empty Microsoft Windows 10 (64 bit) Hyper-V virtual machine.

  • Turn the Windows IIS feature on (including all sub features)
  • Install SQL Server 2014 (64 bit)
  • Create databases on SQL Server 2014: sgmaster, sgnotify, sgvault, sgvaultindex
  • Restore the databases on SQL Server 2014 from the SQL Server 2005 backups: sgmaster, sgnotify, sgvault, sgvaultindex
  • Set compatibility modus to SQL Server 2014 for the SQL Server 2014 databases: sgmaster, sgnotify, sgvault, sgvaultindex
  • Execute SQL “login / user” correction script, found at:
  • Install the Vault Client
  • Verify we have a working Vault Standard v9.0.0 installation.


  • Install Git in my case it was v2.6.4 Git for Windows.
  • During installation make sure, you choose: “Run Git and included Unix tools from the Windows Command Prompt”.
  • Intialize Git, set username and email
  • Create a folder “C:\Projects\Git\MyRepo”
  • Create a GIT repository inside “C:\Projects\Git\MyRepo” by executing: git init.
  • Commit one file (e.g. an .ignore file) to the MyRepo master with a initial commit.
  • IMPORTANT, do a GET of all Vault files to this MyRepo folder, making all files writable




  • Build the solution in release modus.

Now the really import part is adjusting the App.config file


The servername, because I am running the vault2git tool on the vault server this is localhost.


The vault user name used to login to the SourceGear Vault.


The vault user password used to login to the SourceGear Vault.


The Vault repository name, to get the files from


This is the part that will be added to each Vault username to create a Git user email from a Vault username.


This folder must be the Git repository root folder.

This folder should contain a “.git” folder, before the vault2git is run.


The path to the git.exe to use.


At first this is a “;” seperated list of conversions.

Each conversion is a “~” seperated key value pair.

The first part of the conversion is the path in the Vault (in this case the root of the vault “$”).

The second part of the conversion is the Git branch (in this case “master”)

In this case only one conversion is done, namely converting all the files from a Vault respository to a Git repository branch called master.


NOW RUN THE vault2git.exe

It should convert all files from vault to git

note that this takes a long time.

In my case 7MB of Vault Source files took 23 minutes to convert!!


Now that we have a locale Git repository containing all Vault Sources and history, we can push this Git respository to a remote Git respository (in our case a Bitbucket service).

  • Create a Git repository in bitbucket.
  • Add users to the Git repository
  • Adjust the client_max_body_size (we set it to 0) in the files:
    • /etc/nginx/nginx.conf (Use sudo vim, else the file will be read-only)
    • /etc/nginx/sites-available/bitbucket-cache
    • This is to allow large commits
  • Adjust postBuffer: git config –global http.postBuffer 1048576000
    • This is to allow large commits (<= 1GB)


Some additional information and Notes


Moving vault databases

Vault upgrade guide

Vault compatibility chart

SQL “login / user” correction script

USE [master]
IF ( NOT EXISTS (SELECT sid FROM syslogins WHERE name = ‘sgvaultuser’) )
— next access should be granted in the vault database
USE [sgvault]
EXEC sp_grantdbaccess N’sgvaultuser’
EXEC sp_addrolemember N’db_owner’, N’sgvaultuser’
— The following is ONLY for Fortress and VaultPro:
USE [sgdragnet]
EXEC sp_grantdbaccess N’sgvaultuser’
EXEC sp_addrolemember N’db_owner’, N’sgvaultuser’
— The following is for Vault 4.x and above or Fortress and VaultPro:
USE [sgmaster]
EXEC sp_grantdbaccess N’sgvaultuser’
EXEC sp_addrolemember N’db_owner’, N’sgvaultuser’



In my case, something went wrong and I had to rollback from 4.0.6 to 3.1.9.

If you have to restore a old database, make sure you first remove all sofware.

Remove alle databases.

Create a new sgvault database.

Restore the backup to this new sgvault database.