Do you remember Linus Torvald’s talk at Google where he presented Git? He called everyone a moron who was not thinking that Git was the greatest version control system of all time. He especially scoffed members of the Subversion team, who were present at this talk:

https://www.youtube.com/watch?v=4XpnKHJAok8

I’m using Git for three years now. And it has a lot of cool stuff.

Let me mention the three things I like most about Git:

  • Speed (especially in creating and using branches)
  • “git blame”
  • The Git companion product “Gerrit”

To put my thoughts in this blog into context you should know that I’m very old. At least in the context of IT industry. My long experience has given me the chance to use a lot of different version control systems in my professional life. Let me list the most relevant ones:

  • SCCS
  • ClearCase
  • SubVersion
  • Perforce

All of these previous ones were classic central version control systems. Git was the first distributed version control system that I was using. I liked Git from the beginning, but I also knew very quickly that it was more powerful (more complex?) than any of the other VCS I used before. But as a techie I was eager to use something new and cool, and I was sure that soon I could use all the power of Git and it would help and support me in my everyday life as a software developer.

So, time went by…

After using Git for quite some time I still could not leverage the advantage of all this power and complexity. My main job is to invent software. The tools I’m using (like Git) should help me getting my main job done. But after a significant amount of time using Git, I still experienced that with Git I had to deal much more with “low-level” stuff than with any other VCS I’ve used before. Git took more time and more brain capacity from me than any previous VCS. But I didn’t get enough in return to compensate this.

The Git community did quite a good job in spreading the idea that guys who don’t understand Git are dumb-asses and don’t deserve to use Git. I think this mindset has started with Linus “Morons” speech at Google. I began to assimilate this and felt bad being one of these dumb-asses. I thought this might be because of my age and tried not to think about it too much. I especially didn’t dare talking much about it because then all the Git-Lovers would consider me as an old dumbass moron.

Drilling down on the Git perception…

Recently I felt that I should dig a little more into why some people don’t like Git, but even more I wanted to find out more who are the ones that always tell me that this thing is the greatest VCS on earth.

My experience was that those people who loved Git most, are not the ones that use just as a VCS tool (like myself and probably most “ordinary” software developers). It are the ones whose “main job” is to build something “with” or “around” Git.

Let me give you two examples from within SAP. First there are my “EGit” colleagues. They provided the integration of Git into the Eclipse development platform. The other ones are the “Lean DI” guys, who provide infrastructural tools and services in the area of software lifecycle management.

For all these people Git is not only a tool to get their main job done. Git is a significant part of their main job. They deal so much with it, that they finally know every crappy side effect of every Git command. They get used to all this, and in the end they perform every Git related task with virtuosity. On the other hand they are often contextually so far away from the everyday life of an ordinary developer (who uses Git “only” as a VCS) that they don’t understand why people have problems with the power and complexity of Git.

Enough of the people who love Git. How about the other ones? Are there really just a few old dumbass morons that have problems with Git (like me)? Well, first I looked around in the area of colleagues that I work with regularly. One of them is among the best software architects that we have in this company. Another one holds a PhD in astrophysics and has literally done rocket science software (at ESA). The third one holds a PhD in Chemistry and currently working on a topic that would put knots into my mind. All these three guys are intellectually far beyond my skills, but when I talk to them in private they all admit that they are pissed using Git because it sucks out their brains more than any other VCS tool in the past. Git distracts them (not totally, but significantly more than other VCSs) from getting their “main work” done.

OK, three people that I know in person are not so much of a relevance. I checked out what I can find on the internet. Of course I know that for every successful product, there are millions complaining that this product is bullshit. So I didn’t look much on how much stuff I will find on the internet. I focused on WHAT they were complaining about in the context of Git.

What I found had a pretty good match with my experiences. The “ordinary” developers that mainly create software very often felt overwhelmed and confused by the power of Git. Whereas people working in “Software Lifecycle Management” mostly love it. These are the ones who juggle with branches and code-lines and try to create product out of the many contributions by all the software developers.

Actually Git supports exactly the job the Linus Torvalds does in the context of the Linux development. Guess what, it’s no wonder that Linus created a tool that fits perfectly to his needs. And looking at the personality of him, it’s also no wonder that Linus doesn’t care very much about the “others” (morons).

Let me give you a good example of criticizing opinions on Git:

http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Things of that page that I also fully support are aspects like:

  • “Complex information model”
  • “Information model sprawl”
  • “Leaky abstraction”
  • “Power for the maintainer, at the expense of the contributor”
  • “Burden of VCS maintenance pushed to contributors”

Sooooo, what do I want?

Let me start with what I don’t want. I don’t want that Git goes away. Git is the VCS of the 21st century. I like the speed of Git and the ease of Gerrit.

  • I want to talk open about the weaknesses of Git
  • I want that the “Git lovers” stop considering everyone as “moron”, “dumbass” or “too old” who doesn’t also love Git in its entirety
  • I want that Git improves and becomes simpler for the “ordinary development tasks”

But mainly I want that that developers speak up and also tell their doubts about Git and thereby help to improve Git over time.

You are not a moron if you don’t like Git!

Until this this happens, I’ll stay “proud to be a moron”.

Let me close with two statements of Linus Towalds.

The first one is a reply to someone who asked him why he doesn’t use C++ (instead of C) in the Linux development.

*YOU* are full of bullshit. C++ is a horrible language.

Secondly in his famous Git talk he said:

I think the designers of subversion were complete morons. Strong opinions, that’s me, right?

There are a few of them in the room today, I suspect. You are stupid.

So let’s altogether continue using the VCS invented by this lovely guy.

CU

Martin “Proud to be a Moron” Kolb

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Robin van het Hof

    I can fully relate with your feelings. Having used VSS/CVS/SVN in the past, Git appeared quite a bit counter-intuitive for me.

    As I try to stay clear from CLI’s as much as possible — c’mon, this is 2015, I want GUI’s — with Git it seems I was forced to learn all these crazy commands. On Mac OS X, I use the rather awesome Tower – The most powerful Git client for Mac which gives me sufficient power, and at least doesn’t make me feel like a complete moron 😉

    But I do have to agree with Linus; C++ is indeed a horrible language compared to C 😉

    (0) 
    1. Martin Kolb Post author

      Hi Robin,

      thanks for your support! 🙂 ➕

      With respect to GUIs I tried “EGit” because I use Eclipse and EGit was built by my colleagues at SAP. It’s quite OK, but EGit destroys one of the best advantages of Git: Speed.

      With Eclipse’s resource model – which effectively builds a file system on top of the file system – it’s hard to get this done in a fast way (at least on Windows using NTFS).

      So I finally used command line again.

      (0) 
  2. Ethan Jewett

    So you’re familiar with VCSes? I guess you don’t work on ABAP 😉

    (Which is to say, I find blogs like this a bit funny when 2 of SAP’s primary platforms, ABAP and HANA, seem to be of the opinion that version control is for morons…)

    (0) 
  3. Dennis Allard

    Martin, I enjoyed your post, one of several I found at the bottom of the page Subversion vs. Git: Myths and Facts.

    I want to make a minor speculation as to why Git is so hard to learn and why so many people hate it.  Before doing so, a bit of background, I am also an “old guy”.  Trained in Computer Science at UCLA then at UC Berkeley, several years working in research environments, then a couple more decades and counting doing work in the “real world” developing applications.  I have used CVS and Git a fair bit but my use of Git was vanilla, just your simple add/commit/pull/push/pull type uses with very little branching.

    BTW, speaking of branching, I strongly recommend Gitflow considered harmful and it’s followup Follow-up to ‘GitFlow considered harmful’ .

    Recently I needed to explain Git to others so decided to read up and try to “really understand” Git.

    I listened to a couple of good YouTube tutorials and then tried to start creating some example git sessions with simulated clients to illustrate various combinations and sequences of commands.

    Doing so enabled me to do vanilla things but many questions arose.  When and why would my working files change?  What about the index? Why is Git claimed to be a “distributed” system when everyone who uses it synchronizes their work via a common remote repository?

    I quickly encountered the usual problem of confusing overloading of functions, absurdly complex options, utter lack of documentation of semantics (e.g. explain semantics of commands based on input/change of state/output of each command with respect to the underlying objects (working files, index, local repo, current branch, other branches, etc.).

    I decided to begin reading Scott Chacon’s book ProGit.  I then realized something.  The people who expound and Git and even those who developed it do not know how to specify semantics!

    I have done a bit of Linux kernel work so I already had the experience of seeing cultures where the code is the spec so the fact that the geniouses that bring us Linux don’t know how to write or explain something to others did not come as a complete shock.  (-;

    Here is an example of a letter I am penning to Scott Chacon that includes an  example (one of what is surely dozens or hundreds) of imprecise writinng.  I have not yet sent this email to Scott since I am not sure what email  address to use.  I have sent him a LinkedIn Connection request.

    (letter to Scott Chacon

    Hi Scott.

    I am learning Git and see a paragraph in section 3.1 of Pro Git that seems incorrect:

    The book states:

    [BEGIN CITATION

    Note:

    Switching branches changes files in your working directory

    It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all.

    END CITATION]

    First “switching branches” is ill-defined. I will assume that “switching branches” means doing a `git checkout <branch>`.

    If so, then the above statement is false in two cases:

    case 1:
    The branch does not yet exist. In this case, checkout will create a new branch, set HEAD to point to that branch, and leave the working directory untouched.

    case 2:
    The branch points to the same commit as the branch that HEAD points to. In this case, checkout will change HEAD to point to the branch but, again, leave the working files unchanged since both the old HEAD and  new HEAD point to branches that point to the same commit.

    One caveat… if the phrases “changes files in your working directory” and “files in your working directory will change” include the null change, then arguably the above paragraphs are semantically correct.  But you have to admit, they are misleading.

    It is NOT (always) the case that “when you switch branches in Git, files in your working directory will change”.

    Another misleading sentence in that section is:

    “HEAD moves when you checkout”

    Well, no, HEAD is assigned to. If you assign it to itself or to a branch that points to what it already points to, then it does not “move”.  “Move” here is really an extraneous albeit convenient piece of terminology.  A better explanation of the semantics of checkout (well, checkout of a branch, as opposed to checkout of a file — overloading is yet another issue) would include that checkout reassigns HEAD to point to the branch and if that branch points to a different commit modifies the working files to be as of that commit. There is more to say, such as what happens to the index, etc.

    Ultimately, the confusion here is that git makes use of pointers (a branch is a pointer to a commit) and pointers to pointers (HEAD is a pointer to a branch) and is very sloppy in its documentation about describing the input/output semantics of operations that affect various pointers. Were Git documentation to be better specified by defining all actions in terms of input/output semantics on all git entities (HEAD, working files, the index, etc.), it would be easier to learn Git.

    )

     

    So, that’s my comment for now.

    Cheers,

    Dennis Allard

    allard@oceanpark.com

    (1) 

Leave a Reply