Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
By: P. Kelley
On 30 January 2013, we released the first preview version of the Visual Studio Tools for Git downloadable plugin for Visual Studio 2012. We recently became aware of two bugs in this initial preview release that we felt warranted public disclosure. The second preview version of the Visual Studio Tools for Git, version 0.8.0.0 is now available for download, and these bugs are fixed in that version.
Both bugs are related to the support in the open-source libgit2 library for the "core.ignorecase" setting. This setting is on by default on Windows, because Windows file systems (like NTFS) are generally case-insensitive but case-preserving. That is, the filenames "file.txt" and "FILE.txt" both map to the same file on disk.
It's legal for a Git repository to have two directories (also called trees, in Git-speak) with different names according to case-sensitive sorting rules, but identical names under case-insensitive sorting. For example, those directories might be named "Images" and "images". On Windows, when you create a working copy of this structure, the contents of these separate "Images" and "images" directories end up merged together in one directory on your disk, since the two directory names are equivalent. If you created a working copy on Linux, though, you would end up with two separate subdirectories next to each other, named "Images" and "images". Their contents wouldn't be in the same place like on Windows.
We see this scenario most commonly when you have a team using Git to share a repository between UNIX and Windows. However, it's also possible to get this to occur when you rename a folder on your local disk, edit a file underneath the renamed folder, and then commit.
If you do have a repository with this particular property somewhere in it, then you may run into a couple of problems in our 0.7.x.x series of releases. (Again, these are fixed for 0.8.0.0.)
This means that from the point of this commit forward, your Git repository is corrupted. Most Git hosting providers won't let you push these corrupted tree objects up. For example, if you try to push to Team Foundation Service, you'll get an error message that looks something like "The tree object pushed has an invalid structure." To recover your repository, you'll have to cut off the portion of your Git object graph that is malformed and repeat those commits either using git.exe or our latest tools.
Finally, I'd like to point out that these bugs don't just affect the Visual Studio Tools for Git. Other software depending on libgit2 is also potentially affected depending on what functionality from libgit2 is being used. Microsoft has contributed fixes for these issues for the benefit of both our own tools and the entire libgit2 ecosystem.
So now I'm encountering this issue is there a way around it?
Simon: Please make sure you have installed the latest version of the Git tools (8.5.1 at the moment) and see if the issue persists: visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
@Andy With the latest tools installed visual studio crashes as soon as I open my project. Uninstalling allows visual studio to work as normal. I don't typically use the git tools but I'm seeing this problem with all my git tools when I attempt to push to visualstudio.com's TFS. Is there some way to explore the internal git structures to find and correct whatever is wrong?
Simon: Is it possible to post a stack trace of your crash so we can better understand what's happening? You can see the stack by launching a instance of Visual Studio without Git Tools installed, launching a 2nd instance, installing the Git Tools, restarting the *2nd* instance, and using the first visual studio to attach to the 2nd one before you open your project. We aren't seeing this problem internally.