4 ms·
This is a series of articles, and is not yet complete. It starts from a high level description of the organization of the project, and is going into more detail
by lambda 13y ago
This is a series of articles, and is not yet complete. It starts from a high level description of the organization of the project, and is going into more detail as it goes, but it is not yet complete; notice that at the end of the third article there is a "Next: To be published: Git internal algorithms (Tree and Diffcore API)". I presume there will be more after that, though the author doesn't provide an overview of what he expects the full series to consist of.
Also, I don't believe this is intended to be a review looking at coding practices that may cause problems, but rather a review in the sense of a description of a real-world codebase that describes how it works. Think of it in the sense of a review of the literature, a summary of what a body of work is about, not in the sense of a code review that is looking for potential problems that may need to be fixed.
As far as the issues you bring up go, Git is pretty thoroughly cross-platform if you assume a reasonable Unixy/POSIXy platform; while it can be made to work on Windows, it's a bit more cumbersome there; you need to use something that provides at least somewhat of a Unix like environment on Windows, such as MSYS or Cygwin.
As far as resource management and so on go, one of the big problems with the Git code base is that it's designed pretty heavily around a one-shot command model, rather than something which is amenable to being used as a library or in a long-running process. This is reason why the libgit2 project exists, to provide an implementation of Git that can be used as a library and integrated into other applications. Even Linus himself, who wrote the initial Git implementation, uses libgit2 when he wants something that can be used as a library[1].
[1]: https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV