I don't know anything about Fossil, but saying that no one understands Git just makes me think they're ignorant to learning Git. I doubt that's the case, but still, why say that?
Obviously it isn't literal. Myself and many of my colleagues have had confession sessions in which we all admit to regularly shooting ourselves in the foot with git, and needing to have a cheat sheet open, perpetually. That should tell you something, and it really shouldn't tell you that we're willfully ignorant, unless you want to sound smug.
Any system that has consistent-ish rules can be learned. The more rules, and the subtler they are, the harder it is to learn. Git's problem is that it is necessary to know how it really works, to avoid getting into a bad state. It's complicated enough that it is easier than it should be to get into a bad state. The extent of the rules you have to know to avoid trouble does not match the simplicity of the day to day operations you do on the repo.
Because the data model of git and what git actually does has virtually nothing to do with how most people think it works, conversely the limitations of the tools are not well understood and users are seldom able to help themselves. The arcane git options, error messages and documentation are not overly helpful regarding this.
Because most users of git don’t really understand it. It’s really hard to learn properly and so most users just memorize the commands for their project’s workflow and ask the resident git expert to help (or nuke their local copy) when things go wrong.
It’s not hard to “really understand Git”. If anything, it’s the opposite problem—Git’s implementation is conceptually simple enough that the only good mental model the end user could possibly have is the implementation model. Systems like Subversion or Perforce or Fossil probably have even more complicated implementations than Git, and largely that’s to support a dumbed-down mental model that doesn’t require learning how the tool actually works. With Git, you learn how it works and you’re set, more or less.
You've never botched a merge, try to undo it and accidentally lost work? It's happened to me and/or the people I work with roughly once a quarter since I started using git.
You shouldn't be able to lose any committed work in git. If you botch a merge, you can reset to one of the merge parents and try it again. If you botch a "destructive" operation like a reset or a rebase, you can undo it using the reflog, which is essentially a 30-day undo history for every branch in your repository.
No, I can't say that I've ever lost work in that manner in over a decade of using git. The first few times I made a mess of things while trying to do a nontrivial merge it admittedly took a while to figure out how to get back to my starting point, but I guessed (correctly) that it'd be worth spending that time to learn how to do it rather than giving up and throwing away work.
Indeed, that was then intent. The other points are serious, but then I thought "let's throw in a cartoon!"
I just wrote the referenced article last night. Normally, I takes months or years before something like this gets picked up and discussed on HN, and I have more time to refine the text. This one snuck up on me. Come back in a month or two and the article will probably be much improved. You are reading an initial draft.
On the other hand - it is a funny cartoon, don't you think? And it does kind of capture how most people use Git in a snarky kind of way, doesn't it? :-)
Absolutely, xkcd tends to reflect popular sentiment very well. On a different front, you made my day! One reply, and from the creator of SQLite, no less!
I feel comfortable in git because I've mastered SourceTree. Even 'rebasing' regularly seems to put me in the 1% of users compared to coworkers I've seen over the last two jobs I've worked on. I've seen so many git blunders, and experienced them myself.
It's the only thing I've tried since SVN days, but I can totally see the room for alternatives...
