I try to avoid the debugger at all costs, but it does come in handy sometimes. You'll even catch Uncle Bob in the debugger on occasion. When using a compiled language, you basically "lose" the source code once compiled. Of course bytecode languages can be decompiled, but that's beside the point.
We have a number of common library projects that we share between our applications. Usually these common projects are very low-level infrastructure concerns, etc. While these common projects are relatively mature, they do exhibit bugs from time to time. Wouldn't it be nice to step in to the source code of one of those projects while debugging your application?
Enter Microsoft Source Server. It has the responsibility of "indexing" your source code. Specifically, it hooks the PDB files back to the source code, but enables Visual Studio to pull the source from a source control repository, such as Subversion or TFS. That's exactly what we need. In fact, at my company, we've been using this very solution for several years with great success. As part of our build process, we would index the PDB files to facilitate runtime debugging of common/shared projects when referenced in another project while using Subversion for source control.
Enter git. Git is relatively new in the source control world—only about four years old as of this writing. It's even newer in the Windows world with very little tooling support, although that seems to be changing rapidly. Because of this, there is no "Git adapter" to use with Microsoft Source Server.
I looked around the internet for anyone who had written anything related to Git and Microsoft Source Server. I found one article, which turned out to be exactly what I needed. Well, almost. In the end, I completely re-wrote the implementation to be a little bit more "Clean Code" and to support distributed workflows better, even though I'm not a Perl programmer. The end result was SourceServer-GitExtensions.