4 ms·

Seems a shame the "15" team have given up on libgit2. Considering Microsoft have / are a contributor _and_ presumably all contributing parties have the same goa

Seems a shame the "15" team have given up on libgit2. Considering Microsoft have / are a contributor _and_ presumably all contributing parties have the same goal (cross platform, feature parity etc) one has to wonder what's so bad with libgit2 it's been dropped in favour of shelling out to git.exe?

Osiris 10y ago
Seriously. Git for Windows is frustratingly slow in my experience. I've been waiting for a good fit client on Windows that leverages libgit2 for performance, but I'm not aware of any.
- james-skemp 10y ago
  I don't know that it leverages libgit2, but SourceTree is something we use and while I was initially unsure, it and PowerShell are my preferred ways of working with git. (I maybe use VS's git integration once a week or so.)
treebeard901 10y ago
It's likely a problem with Visual Studio being a 32-bit application and less to do with git. This is why they referenced running git out of process to save a few hundred megabytes of memory.
- ethomson 10y ago
  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.

Osiris 10y ago

Seriously. Git for Windows is frustratingly slow in my experience. I've been waiting for a good fit client on Windows that leverages libgit2 for performance, but I'm not aware of any.

james-skemp 10y ago
I don't know that it leverages libgit2, but SourceTree is something we use and while I was initially unsure, it and PowerShell are my preferred ways of working with git. (I maybe use VS's git integration once a week or so.)

treebeard901 10y ago

It's likely a problem with Visual Studio being a 32-bit application and less to do with git. This is why they referenced running git out of process to save a few hundred megabytes of memory.

ethomson 10y ago
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.