Continuing the theme of my previous post about Git. You don’t need to know much about software development to read it.
I have a love/hate relationship with Git.
Git made its first major appearance on the Free Software community scene in style with the famous Linus Torvalds’ talk, a large part of which consisted of verbal abuse against Git’s main competitor, Subversion (a.k.a SVN). Torvalds did it in a funny and cute way, so that was forgivable, and the serious technical part of his talk was very interesting and convincing, so i tried installing Git and using it. I didn’t quite understand what is it good for, though, and it wasn’t as popular then, so i forgot about it for some time.
A couple of years later i went to work in another company, which didn’t use any kind of source code management system at all. We would just email zipped source trees to each other. It was bogus, so i proposed installing some kind of an SCM and my boss just told me that i can suggest any product i like. Recalling the apparent coolness and sexiness of Git, i tried installing it locally and worked with it by myself for a few days, and it was mostly OK.
After some time i wanted to create a branch to test some new feature i wanted to develop. Branching is touted as Git’s strongest selling point; everybody keeps saying that it’s very easy and robust in Git. So i tried creating a branch. I worked on the branch for a few days, switching between the branch and the master every few hours when i worked on different things. After a few days i realized that the source tree became completely screwed up because of that.
At that point i had to choose between searching for The Git Way of cleaning up the mess that was created by Git’s “robust” branching capabilities or to simply rewrite the screwed-up files by hand. Searching for The Git Way would take an unknown time of reading through cryptic documentation; rewriting the files would take a known time of some boring repetitive work. I chose the latter option and after i finished the manual recovery, i recommended my boss to install SVN.
Fast forward to 2010. GitHub, a website for gratis hosting of Git repositories of Free Software projects became very popular. I don’t quite understand why, given Git’s immense complexity, but that’s the fact. I want every now and then to send a patch or a Hebrew translation to projects hosted in GitHub, and every time i have to suffer through Git’s cryptic commands to do it. It’s just never quite the same; every time there’s a different problem. Git’s error messages make me feel like i’m punished for not knowing Git.
In one interesting project, for example, i got the source (“clone” in Git terms, “checkout” elsewhere) and i read it. After a couple of days i wanted to start writing a patch and i wanted to update my local copy before that, so i ran “git pull”, which is the command that is supposed to do the update. I started receiving messages about conflicts between the updated files and my local changes; the trouble is that i hadn’t made any local changes. After fighting with Git to resolve the conflicts for about ten minutes i gave up on that project. That’s just one example out of many.
I still didn’t want to give up on Git completely, though. Mostly because i felt that i will want to contribute to projects on GitHub every now and then. So i tried to read Git’s documentation yet again and found gitglossary. You know, i’m a linguist, i love dictionaries and glossaries, and this glossary is actually pretty good, because it really helps understanding the other parts of the documentation. There are a few missing words there, however, so i decided to contribute the missing definitions by finding them elsewhere and sending patches.
During the course of my searches i came upon The Git Wiki. Usually when i arrive at a wiki i open an account there; i have accounts on dozens of wikis, not counting the different languages of Wikipedia. The first thing i usually do after i open an account is to create a user page, which is usually called “profile” on other sites, and put a link to my blog on it, because that’s the easiest way to tell the world who i am.
When i did that on the Git Wiki, an administrator of that wiki deleted my user page, saying that it was “link spam”. That never happened to me on other wikis, so i sent him a message through his user page, which is the usual way of communicating between users of wikis, and i asked him what was so bad about what i had done. He deleted that message and blocked my account, saying that i was abusing the user talk page for messaging and abusing him as an administrator. I didn’t want to give up and i sent him an email, trying to explain my intentions. He replied by saying that it was impolite on my behalf not to say “Hi” in the beginning of my email.
Maybe Linus Torvalds gave a bad example after all.
Git is the single most frustrating piece of software i ever encountered and dedicated Git users are the most arrogant and patronizing bunch of people in the Free Software world. Not all of them, obviously; Jamie, who patiently replied to my rants the other day is nice. But except him nearly all of the Git people with whom i had contact were extremely unwelcoming, as if they were trying to protect their elite community from dumb outsiders. Indeed, getting into it is so hard that maybe those who succeeded to penetrate it became hardened by the struggle. Many, many times i just wanted to give up and decide to stop using it for the sake of my mental health. Yet Git has this strange sexiness that keeps attracting me and i don’t have an explanation for it. A kind of masochism, i guess.
This post is filed under “Wikipedia”, because the accusations similar to the ones i am making here against Git and the community around it are frequently made against Wikipedia. For years hard-core Wikipedians, including myself, lived in denial, saying that it’s not so hard to join Wikipedia, write articles and become part of its community, but many people kept complaining that Wikipedia is very hard and unwelcoming, both technically and socially.
This wall of denial is starting to crumble. The Hebrew Wikipedia community tried to deal with this problem recently by inviting a group of academics to a meeting where prominent community members tried to explain to academics in simple terms what Wikipedia is, what is good and what is bad about it, why Wikipedia wants academics to join it, and what are the easiest ways for academics to join. I am also trying to draft people to Wikipedia by proposing them to just send their contributions by email, thus passing by the technical hurdles that the Wikipedia user interface poses.
These steps certainly do not solve all the problems, but at least we acknowledge that problems exist. Does the Git community acknowledge that it has such problems? I doubt it, but i’ll be very glad to be proven wrong.
