-The C code seems to follow some sort of modular or OOP like design. A lot of the functions have prefixes to indicate which datatype they operate on, and they are grouped together in file with similar name.

- I fail to understand how you think git is abuse of unix philosophy. Users don’t have to see individual commands since they are launched through the git command. A lot of small executables is great because you can test each individual feature separately. It also allows advance users to build new tools by chaining together executables with their own scripts.

- I wish the software I work on was designed like this and not as a monolith, where it is pretty much impossible to test individual components. Sure we had a plugin architecture at one time and some sort of modular design. Except that was all in C++ and over time people abuse it and break it to the point where plugins are so dependent on each other that they cease to be individual components.

With the git design there is less chance of this happening since the individual components are processes which can suddenly start depending on each others internals.

I am so sick of this kind of attitude from nieve open source hackers.

It has advanced A LOT in very short time, sure you will find it quite feature complete.

I wanted to add a feature to git. I found it fairly easy to figure out where to put it and how to write it. I did make a couple of mistakes in my initial version (which were pointed out to me early). Making git do what I wanted it to do was easy. The hard part was getting it accepted.

Junio has got to be one of the busiest software volunteers on the planet, but he meticulously reviewed my code for both style and function. I had to send it through several times and wrote *way* more unit tests than code. In the end, it made my confidence *really* high.

Large functions are not correlated with higher defect rates (http://www.informationweek.com/news/software/open_source/showArticle.jhtml?articleID=207801458). You can watch Steve McConnell wrestle with this in CC/2e if you care to read about it. He suggests giving up at around 150 lines (and I tend to agree), but I think this has more to do with wearing out your page up/page down keys than with code quality.

Why are you trying to understand the source code without a serious investment of time and energy? There are two possibilities: A) (most likely) have an axe to grind and are trying very hard to find problems with Git or B) (less likely but possible) you have very serious misconceptions about software design. Large software systems are inherently complex, and you have to make a major investement of time and energy in order to understand them. You say browsing the source files is painful…of course it is painful! It is painful because you are not familiar with the rules of the Git project, and that pain is your mind stretching to fathom the
vastness of the new mental terrain.

You say the API is lacking in part because some of the programs call exit() on failure. You should learn how to open a pipe to a subprocess. Try this:
$ python
>>> import subprocess
>>> help(subprocess)

Git is not perfect, but your criticisms are very weak.

You have to understand that companies have a variety of people of varying skillsets who all need to use the repository. It’s not reasonable to ask a graphic designer or an HTML/CSS coder to move from Windows to UNIX and use a command line tool to do their commits.

A lot of times, the programmer ego comes into play and people say “if so and so can’t figure it out, they’re just dumb/ bad at their job/etc”, but it doesn’t make sense to spend significant time and money training people to use an immature system just because it’s theoretically the latest and greatest.