Abuse in the Git Community and in the Wikipedia Community

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.

About these ads

9 Responses to “Abuse in the Git Community and in the Wikipedia Community”


  1. 1 Ævar Arnfjörð Bjarmason 2010-08-07 at 16:09

    Here’s some replies to the issues you had, in order.

    First, you seemingly created a project in Git, used branches a lot, had merge conflicts, didn’t know how to solve them and then decided to throw the baby out with the bathwater. And ironically picked SVN where this sort of workflow would have been a lot more painful.

    Git isn’t the fairy godmother. If you’re changing the same lines in the same files in many different branches you’re going to have merge issues. And you’re probably going to have to solve those manually.

    Git makes it easy to do that when it happens. You get a merge conflict, solve it manually, “git add” the files that had issues, and then “git commit”.

    What it can’t do is magically make things right. It’s not the fairy godmother.

    Secondly, the git pull issue. There’s pretty much no way that could have happened as you describe it. If you “git clone” and then “git pull” later you’re *not* going to get any conflicts unless you have local uncommited changes.

    One way that might have happened is if upstream had force-rewritten their upstream repository. But then I think you wouldn’t get a message about a conflict.

    In short, that one sounds like you’re misremembering. “git pull” on a repo that can be fast-forwarded (you haven’t made any changes) *will* just work.

    Thirdly, that wiki incident just sounds like some admin having a bad day. I can see why an admin who no doubt deals with a lot of drive-by-spam would be overzealous about deleting an account whose first and only action is to create a user page consisting of a link to an external blog. That just looks a lot like drive-by linkspamming.

    Anyway, most of this Git stuff is pretty simple once you get the hang of it. But Git is a tool that’s solving a non-trivial problem. While of course we’d all like everything to be as easy as playing SMB a tool can only be as simple as the problem it’s solving.

    There is a certain complexity about a tool that manages multiple divergent commit histories that will always have to be offloaded to the user, because he’s the one that knows how to merge it, and which version he wants to keep.

    Managing that is easy once you get the hang of it, and it’ll save you a lot of time in the long run.

    • 2 aharoni 2010-08-07 at 16:17

      First, you seemingly created a project in Git, used branches a lot, had merge conflicts, didn’t know how to solve them and then decided to throw the baby out with the bathwater. And ironically picked SVN where this sort of workflow would have been a lot more painful.

      Having heard that in SVN it’s hard, i wouldn’t have tried to do that in SVN in the first place. I would just do what about 90% of programmers do in such a case: copy the files do a different directory and manually do a diff later.

      Git lovers say that branching is easy in Git, so i tried to see whether it really is easy. It’s not.

      Secondly, the git pull issue. There’s pretty much no way that could have happened as you describe it. [...] In short, that one sounds like you’re misremembering.

      … And yet it did happen and i am not misremembering. I just ran two commands, so there’s isn’t too much to misremember. That’s exactly the kind of response i refer to when i’m saying that i constantly feel that i’m punished for not knowing Git.

      • 3 Ævar Arnfjörð Bjarmason 2010-08-07 at 16:58

        Having heard that in SVN it’s hard, i wouldn’t have tried to do that
        in SVN in the first place. I would just do what about 90% of
        programmers do in such a case: copy the files do a different directory
        and manually do a diff later.

        I would hope that 90% of programmers would make an effort to
        understand the system they’re dealing with and solve the problem,
        rather than just falling back on some ad-hoc monkeypatch solution.

        The whole point of using a SCM is that this sort of thing is *easy*
        once you put in the effort to learn how to do it. You’re not going to
        get to that point if you refuse to learn.

        At no point in this posting have you indicated that you even tried to
        solve the issue. Did you e.g. try to Google “how to solve merge
        conflicts in git”? That would give you the git-merge manpage which has
        an all-caps “HOW TO RESOLVE CONFLICTS” section pointing to all the
        stuff you need to do in cases lik ethese.

        You hopefully wouldn’t say, hard-reset a RDBMS because it threw some
        SQL error you don’t understand at you, or throw away a days work on a
        C program because you’re having a hard time dealing with some memory
        corruption bug you introduced.

        Git lovers say that branching is easy in Git, so i tried to see
        whether it really is easy. It’s not.

        It is. But what isn’t “easy” is recovering from merge conflicts that
        result from you changing several divergent trees in incompatible
        ways. You’re always going to have to solve that sort of thing
        manually.

        But even when you have to solve that manually Git makes it much easier
        than it otherwise would have been.

        Which brings us back to the fairy godmother point. Git’s just a tool,
        not a magic wand.

        You can’t expect to effortlessly do that sort of thing in *any* system
        without understanding what’s going on.

        … And yet it did happen and i am not misremembering. I just ran two
        commands, so there’s isn’t too much to misremember. That’s exactly the
        kind of response i refer to when i’m saying that i constantly feel
        that i’m punished for not knowing Git.

        I’m not punishing you for not knowing Git. I’m saying that your report
        of what happened doesn’t make any sense at all.

        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.

        When you “git clone” a tree you fetch it and check out a copy of
        it. If you then *don’t touch it* and later come back and “git pull”
        everything will *just work*, because the update you’re doing is known
        as a “fast-forward” merge. I.e. it sees that.

        1. Your working tree hasn’t changed

        2. Your history is a subset of the remote history, i.e. you haven’t diverged.

        3. It can then just fetch the remote history and update your working tree without conflicts

        The *only* exception to this that I can think of would be if someone
        on the remote side had done a forced push on the remote site in the
        meantime. This would be the equivalent of someone using Subversion
        doing rm -rf on the server’s SVN repository and starting from
        scratch, just try to svn up from that.

        Instead you had:

        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.

        Sorry, but I believe Git over you in this case. If it says you had
        local changes and triggered a merge conflict I’m pretty sure you had
        local changes. I have a copy of the Git sources I can validate that
        assumption against, I don’t have a copy of your brain.

        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.

        So you’re fighting to resolve conflicts that supposedly didn’t even
        happen? What sort of conflicts were these? From the previous
        description they should (in the unlikely case that Git somehow went
        bonkers due to a forced update) have only been conflicts between
        different versions of the upstream history, not something you had to
        worry about.

        • 4 aharoni 2010-08-07 at 17:16

          At no point in this posting have you indicated that you even tried to solve the issue. Did you e.g. try to Google “how to solve merge conflicts in git”?

          At no point in this post have i indicated that i had merge conflicts. I indicated that my source tree became completely screwed up. I had files that disappeared or were reverted to their state from several days earlier and i had no idea where the changes that i made were hiding.

          Yes, of course i tried reading, or more precisely, deciphering the docs for some time, but i’m paid for programming, not for deciphering docs. With SVN i am very efficient without reading docs and despite Torvalds’ claims to the opposite, using SVN is better than emailing tarballs.

          Sorry, but I believe Git over you in this case.

          You’re free to do it, but if you want the software you develop to be used, try believing your potential users from time to time. Denial has its costs.

        • 5 Ævar Arnfjörð Bjarmason 2010-08-07 at 17:25

          At no point in this post have i indicated that i had merge conflicts. I indicated that my source tree became completely screwed up.

          Yes, I erroneously assumed that you had conflicts.

          I had files that disappeared or were reverted to their state from several days earlier and i had no idea where the changes that i made were hiding.

          That sounds like you were just on the wrong branch. You’d have the same issue in SVN if you checked out the wrong /branch/* directory.

          In any case, you can find out where your missing patches are with git log –all -p or git reflog -p.

          You’re free to do it, but if you want the software you develop to be used, try believing your potential users from time to time. Denial has its costs

          It’s not denial. I’ve determined that your report, as it stands, doesn’t make any sense. Because git simply wouldn’t do that. Just like SVN wouldn’t throw conflicts if you svn up in an old directory that you haven’t edited anything in.

          Do you have exact steps to reproduce this issue? I can guarantee you that you can do fast-forward updates on undivergent histories all day without running into anything approaching a conflict.

          So that pretty much just leaves the possibility that you’re misremembering something, I find that far more likely than you running into some one-off heisenbug in git on an everyday operation.

        • 6 aharoni 2010-08-07 at 18:16

          That sounds like you were just on the wrong branch.

          Obviously that’s the first thing i thought then. Except that i couldn’t find any way to get on the right one. And frankly, i was afraid to ask, because already then i tasted the all-too-frequent arrogance of some of the members of the Git community.

          Do you have exact steps to reproduce this issue? I can guarantee you that you can do fast-forward updates on undivergent histories all day without running into anything approaching a conflict.

          Hope it helps:
          * The project is: http://github.com/chromatic/modern_perl_book/
          * I cloned shortly before i opened issue 95. I tried to pull shortly after chromatic sent his second comment about that issue.
          * The files about which git complained were sections/chapter_*.pod , not all of them. I don’t remember which ones exactly, something like 00, 03, 06. I gave up after doing a checkout on a few of them, because it didn’t make sense to try fixing a problem which i didn’t – and still don’t – understand.

          Nice folks on IRC who noticed this blog post said that it may be related to line endings. I use Cygwin and if i’m not mistaken, chromatic uses a Mac, so that is possible. If it’s true, it’s still a problem, because i had no way to guess that that’s the reason behind the cryptic messages.

          You can’t have a copy of my brain, but if you really want to understand what happened, i can send you a zip of my repository.

        • 7 Ævar Arnfjörð Bjarmason 2010-08-07 at 19:00

          Obviously that’s the first thing i thought then. Except that i couldn’t find any way to get on the right one. And frankly, i was afraid to ask, because already then i tasted the all-too-frequent arrogance of some of the members of the Git community.

          We’re friendly :)

          Seriously though, #git is amongst the most helpful IRC channels out there, and you’ll get quick help on the Git mailing list too.

          Nice folks on IRC who noticed this blog post said that it may be related to line endings. I use Cygwin and if i’m not mistaken, chromatic uses a Mac, so that is possible. If it’s true, it’s still a problem, because i had no way to guess that that’s the reason behind the cryptic messages.

          I didn’t consider that you might be using the fringe Windows platform.

          But yeah, that sort of issue can probably be caused by a misconfigured auto-Windows line ending rewrite. Git has some fragile support for automatically rewriting newlines as they go out and into the repository on Windows.

          Likely that went wrong in your case, so that you had a copy of the tree with everything as \r\n in your checkout, but the upstream had \n which conflicted with that.

          I haven’t used that area of Git (and never plan to, the whole concept is very urghl). But it probably shouldn’t break like *that*.

          Anyway, I think we’ve gotten to the bottom of that issue, kinda.

        • 8 aharoni 2010-08-07 at 22:15

          I didn’t consider that you might be using the fringe Windows platform.

          Cygwin, not exactly Windows, and even as a joke you shouldn’t consider either of them to be fringe.

          Setting autocrlf to input seems to fix that problem, although i’m not sure about anything anymore. And that’s the most frustrating thing about Git, really: it is “advertised” as very secure and robust in comparison to other SCM systems, but i always had the opposite feeling about it.

  2. 9 Dan 2010-08-09 at 09:21

    Interestingly, I had my first experience with git in the last week.

    The person who showed it to me was a strong advocate, and in general managed to show me the ropes pretty quickly, although the “glossary” wasn’t intuitive to me as I am used to the CVS/SVN jargon. I find git very nice, and I like the “git gui” and “gitk”, I think they give the user a very good picture of what’s going on.

    It wasn’t very long before we realized that something was terribly wrong when I try to work with the system. I’ll cut to the end: I was using a mac, they were all using Windows. The “autocrlf” flag solved only half of the problem, in the sense that I could view diffs correctly, however I could not run my committed shell-scripts because bash complained on bad line endings. I ended up deleting the autocrlf flag and re-committing my files with unix line endings.

    Our conclusion from the experience was that we still don’t understand git well enough to be using it from different platforms. For good measures, let’s mention http://help.github.com/dealing-with-lineendings/ – a must read for “fringe platform” git users. Maybe the answers hide in there somewhere. I would still like to try git some more.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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





Follow

Get every new post delivered to your Inbox.

Join 1,704 other followers

%d bloggers like this: