Yes, this is exactly it. Calling git as a separate process clears up the cost of libgit2. And not just one copy of the library, since there are so many users

Yes, this is exactly it. Calling git as a separate process clears up the cost of libgit2. And not just one copy of the library, since there are so many users of git within Visual Studio (Team Explorer, GitHub, CodeLens...) there are at least two copies of the library being loaded. (GitHub ships a newer version of libgit2 in VS prior to 15, intentionally. The Microsoft teams should use a single version, the one included with Team Explorer, but communication is hard.) By dropping libgit2, they freed up some memory. Obviously the overall memory usage of VS and `git` is probably _increased_ but VS teams are flogged until memory usage decreases because nobody will prioritize making it a 64 bit app. (Opposite, in fact: https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu...) There's also the issue that Microsoft hired the maintainer of Git for Windows and lost a maintainer of libgit2. It's not an ideal situation for libgit2, we certainly liked our relationship with the VS team, but we understand and sympathize with their decision.