One of my favourite things about git is that the underlying storage and protocol is really simple and straight-forward to implement. You could do a lot of it in shell scripts, if you wanted to.
The stateless storage is simple and consistent, but the thing that does vary is the various operating algorithms: diff, merge, garbage collection, etc.
This creates a really interesting ecosystem where you could potentially have third-party tools that have some secret sauce producing more efficient diffs or fewer conflicting merges but still base it entirely on the open git ecosystem and remain completely backwards-compatible with all the other tooling.
> And they're going to do so in a way that isn't immediately detectable, but screws the rest of the company because now they have to support something using the screwed up implementation.
eeeeeeeeeh. Sensible companies will figure out how to massage the broken data into the correct form, then go on using the correct software.
If libgit2 is fully mature, I can imagine more GUIs/tools will be built to manage/analyze the git repositories.
For what it's worth, all of the Git functionality in Visual Studio uses libgit2.
I also remember some blog post going into sync/async details of git.exe vs libgit2 stuff. Will try to google it.
The AsyncReaderWriterLock mentioned in blog does not directly show up in Google, but it appears to be based on the one in this blog post: http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/building-...