Some thoughts on git

As I mentioned in a previous post, we started using git for managing Tagua source code. There’s currently a lot of controversy in the topic of distributed versus centralized VCS’s, and I feel like expressing my own ideas, too. 🙂
I’m no git guru (yet), so please don’t get offended if I missed something in my criticism. I hope to generate a fruitful discussion, because I really think that the VCS is an important element in the development of an open source project.

Why git rules

  • It’s decentralized. I fully agree with Linus on this point: the decentralized model is superior, for various reasons I won’t talk about in detail here.
  • It’s simple. I don’t understand why people keep complaining about git being overly complicated. The object model is fairly straightforward, as soon as you stop thinking about revisions the cvs/svn way, and branching/merging is trivial.
  • The object model is very well designed, flexible and useful.

Why git sucks

Well, git has a number of minor (?) defects, like portability issues, impossibility of doing partial checkouts (actually I think this is a problem with all the decentralized VCS’s) and stuff like that, but let me concentrate on those issues which are fundamental to git as an open source project, and are unlikely to be addressed in the future:

  • It is written in (unreadable) C. I don’t want to start a flame war (really!), but browsing through git’s code is a painful experience. Huge .c files with tons of big functions with no apparent structure and almost no comment. Ubiquitous micro-management stuff for handling manually allocated buffers. In other words… a mess.
  • It (ab)uses the UNIX philosophy. Do one thing, and do it well. Yeah, of course it’s a great idea, but maybe they shouldn’t have taken it too literally. I mean, if we talk about modularity and reusable components, I’m all for it, but it doesn’t mean you have to make a different executable for each task (even low level ones that should be invisible to the end user) and chain them together via text pipes and bash scripts!
  • It’s not reusable by third party applications, at least not in any efficient/convenient way. If you want to build a higher-level abstraction over git (a so-called porcelain), you need to fork out every now and then to get input from git, and then parse its textual output. Yes, I know about libgit.a, but that’s not really usable as a library (half of git functions call exit on failure) and has no API documentation at all.

That said, I have to admit that most of its defects aren’t that important if you are just going to use it, and not develop it. However, using something you have problems inspecting and modifying feels a bit like using a closed source product…


Tags: , , , ,

23 Responses to “Some thoughts on git”

  1. slougi Says:

    another (imo big) minus point is that it does not really work well on windows

  2. El Anonimato es Cojonudo Says:

    Who cares about windows?

    Let Microsoft develop its own software development tools. And if you “need” to run windows, run it in a vmware session.

  3. baxnick Says:

    mm, I really dig the progress of IDE integration with subversion. It’s a only a minor convenience really, given my workflow, but it’s a convenience I enjoy.

    What I love about git is how easy it is to get up and running for a smaller project, or for local tasks like keeping versions of modified etc/ files. No stuffing around with creating a repository, importing and checking out. Just git init, git add., git commit, and away I go. I find it perfect for uni projects.

  4. Maurizio Says:

    1 Please let’s not make of Paolo’s blog a forum a about how bad/good Windows is.
    2 slougi: what does it mean that it does not “work well”? That there is no native windows GUI? On Linux it is a just very useful command line tool, i don’t understand why just being command-line makes it a bad tool on Windows. Or is there really some windows-specific problem? A part from lack of support, git is not a very os-specific tool, so it should work ok with Cygwin/MinGW.

  5. Mark Williamson Says:

    Mercurial is worth a look. It has a similar feature set to git, and is written concisely in (surprisingly few lines of) Python. The core is very hackable, and there’s an extension API for adding certain extra functionalities. Only really performance critical stuff is written in C, but the overall application is comparably fast to git. It uses a bit more disk space than packed git.

    It also has some nifty features, e.g. the ability to create a “bundle” of a repository of a set of changesets to e-mail or put on a server somewhere.

  6. Jon Says:

    Now for my two cents. 🙂

    I agree with Paolo on the negatives of Git. Therefore I recommend the following:
    Paolo, I suggest that you to look at a real VCS, like Bazaar:
    It’s a distributed VCS, like git, but it has more features than you can imagine. You can even use regular file system tools with it, like rm, mv, edit … so forth. It even has features that if you set it up in a certain way it will act partly like a centralized system, but not fully centralized. It even has svn aliases for those that want to switch. There are plugins that allow you to connect it to other VCSs like svn and even git to sync with them. The code is well written, in my opinion, and it is very stable It’s been in development for a long time. Check out the site and judge for yourself. 🙂 I don’t think you will regret the change from git to bazaar. I never regretted moving from svn to bazaar. Also, they don’t have a new release every week, like git does. 😛


  7. Andy Says:

    If we’re all posting our favourite VCSes, I’ll suggest Darcs.

    In particlar I like how it operates on patches so things can be grouped in a more meaningful way than just when they were committed. (By which I mean commits can be split up into just what they were fixing, etc, though you can also add to existing patches if you haven’t sent them on yet.)

    However if you don’t know Haskell then it being written in a crazy moon language (as I gather Haskell is often regarded 😛 ) may be a deal breaker if you want to be able to look through the source…

  8. Quintesse Says:

    Well others have looked long and hard at the available options out there, so you could take a look at what they found. The OpenSolaris and Java projects for example have moved or in the process of moving to Mercurial, but they did some research beforehand.


    They evaluated Bazaar, Git and Mercurial:

  9. Jon Says:

    Quintesse, those are really good eval reports. They tried to be unbiased and did a great job. However, version 0.9x has come out for Bazaar (bzr) and they have support for correctly handling if someone renames a folder or moves a folder to a new location or moving files. Merge can handle that perfectly. I think newer versions of Mercurial have come out as well. I hope someone compares the new versions. My personal belief is that if v0.9x of bzr is compared using those tests, it will win over Mercurial now. It has really advanced to be something really great. 🙂

  10. Quintesse Says:

    Sorry, just noticed I copied the Bazaar link twice instead of the Mercurial one:

  11. Quintesse Says:

    @Jon: I think it would be nice to see how they compare now, because Bazaar does seem to have evolved a lot since the version 0.7 they tested. I certainly hope they did something about the performance because a 16 minute check-in for a single file is horrendous of course. (I did see several performance related entries in Bazaar’s changelog, so there’s good hope)

    I’m pretty satisfied with Mercurial myself and although I don’t really care what SCM to use I do have 2 requirements:

    1) Cross platform
    2) Good tool support (which means integration into Microsoft’s tools and Eclipse/NetBeans/etc plugins for my Java development)

    #2 made me switch from my preferred IDE Eclipse to NetBeans 6 for example because the Mercurial plug-in for Eclipse sucks. No plugin-in? Not using it.

  12. Roderic Says:

    Hi Paolo. Ya, i do agree that there’s a lot of micromanaging and complexity in git, but that’s really done on purpose, and is the reason why it’s so ridiculously fast.

    Also, for those asking, git doesn’t work well on windows because it relies heavily on file system processes that are simply slow on windows, and shell scripts, some of which don’t work with windows without cygwin (sometimes not even then).

  13. Jakub Narebski Says:

    Two of complaints are being addressed now: there is ongoing builtinification effort to move _mature_ git commands from scripts to C, so no longer lots of forks and pipes. There is also start (stubs actually) of API documentation.

    As to being reusable by third party applications: there was/is GSoC project about git libification which produced something called libgit-thin; but IIRC it is unfinished and stalled a bit.

  14. pcapriotti Says:

    That’s good to hear. I hope libgit-thin gets more attention, because it could be really important for projects like, for example, StGIT, or the git plugin for Trac, which at the moment is unacceptably slow.

  15. Jim Keller Says:

    >Who cares about windows?

    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.

  16. David Says:

    With reference to your comments about Git’s source code, I do not believe your arguments are valid. Unix philosophy is about many things, one of them is isolating functionality into small programs so that errors in one program do not corrupt the others. Git does this. Another is emphasizing the importance of data structures in system design. Git does this.

    Large functions are not correlated with higher defect rates ( 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.

  17. pcapriotti Says:

    Of course browsing through the code of a large and complex system is always somewhat painful. I was just reporting that my experience with it has been particularly unpleasant if I compare it with the effort needed to understand other (also big and complex) code bases that I worked with.
    About the exit on failure thing, it’s not about spawning a subprocess. Exiting from a subprocess is ok. The point is that if you call exit in a library, the calling process will terminate, and that’s almost never what you want.

  18. Dustin Says:

    I don’t see the problem with the source code. I had the opposite experience, really.

    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.

  19. Rick Says:

    @Quintesse: If you want Mercurial support for Eclipse try

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

  20. Anonymous Says:

    I believe the –depth clone option will give you that partial checkout you are looking for.

  21. RealityMistress Says:

    (cross-posting my comment from the blog here in case I ever want to find it again) I don’t see the problem with the source code. I had the opposite experience, really. 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.

  22. Alex Says:

    El Anonimato es Cojonudo Says:
    October 8, 2007 at 2:43 pm
    “Who cares about windows?”

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

  23. Erik Says:

    I don’t think your criticisms of git are very well thought out. I am C++ guy but looking at the code I think it is quite well designed. I don’t think it is really that hard to grasp. Some points:

    -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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: