This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out.

Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

I think that comic also accurately describes the problem leading to that as well: it dismisses any explanation of Git's underlying mechanics and repository structure as ignorable rambling prefacing the command to do what you want.

It took me a while to learn git, and the explanations I went through involved the underlying structure of the repository. They seemed excessively complicated at the time, compared to memorizing commands for cvs and svn. However, now that I understand that underlying structure, every new git tool or function just provides additional means of transforming the repository structure I have into the repository structure I want.

You don't stop learning programming once you've memorized a rote sequence of steps to run a half-dozen algorithms on a hash table. And you don't stop learning git once you've memorized a rote sequence of steps to run a half-dozen algorithms on a git repository structure.

I don't mean that to suggest that git has no room to improve in its UI; far from it. But that particular comic seems to excuse a self-perpetuating problem of not wanting to learn something useful, and instead relying on people who did learn that useful thing while simultaneously belittling them for knowing it.

One of my problems with git is that I don't want to have to understand anything and source code control. It isn't something I am interested in. All I want to do is merge from upstream and commit my changes. Mercurial lets me do this without needing to understand much, whereas git makes me understand all sorts of stuff just to get this basic job done. Why should I have to understand the structure of the repository to merge something? Seems like a classic case of the UI exposing the implementation details. I get that if you are managing a large project you might want all of Git's features, but since that's not me, I just do what the XKCD comic suggests.

Learning git internals can be useful but I'm really sad that its also required. If git's UI weren't so leaky a beginner would be able to go very far with just the "graph theory model" as guidance, which is much simpler to understand.

That's the problem with git. It's extremely powerful, but requires a lot of knowledge to use well. It's a lot like a F1 racing car: the performance of such a car is phenomenal compared to a regular car, but the driver has to really know what he's doing to operate the thing at all. Just google for "F1 steering wheel" to see the controls they have to operate.

Honestly I think it's an accident of history that git became so popular for software development outside of Linux kernel development.

It doesn't help that git is really a good example of evolution, as seen in the UI. It would have been better if it had been architected more thoroughly before releasing for general use.

> The moment something ridiculous needs to be done like a rebase

Rebase, "ridiculous"? Uh oh. It's a very valuable tool and it's a quite simple concept. I agree that the user interface could be less confusing, though.

Git is just a malleable graph made out of patches. The concept is really simple (even simpler than hg). The UI could be better but the manpages are rather good at explaining how it works.

Just because something is conceptually simple does not make it simple to use. Similarly pointers are simple. They are things (usually variables) used to point to other things in memory by storing the memory address of the target. They are simple. And yet their usage is very complex.

Ridiculous, as in, a case where we actually need it is rare enough that by the time the need arises, everyone's forgotten how it works.

We're not in a shop where one-off merge commits are a thing anyone really cares about, so rebases usually mean things like "Somebody used the wrong committer name" or "Somebody did a branch merge incorrectly and now the history makes no sense".

The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

(1): The, IMO, canonical example for awful documentation design - why does a user credential switching program open with a primer to EBNF when it's hardly necessary?

> The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

Perhaps that's might apply to some git manpages, but man git-rebase in particular is really good. It has exactly what you want, example situations, the command lines to achieve them, complete with pretty ascii art diagrams.

It could still be improved, though. There might be some "oops I screwed up, what next" situations too. I think `git rebase --abort` works most of the time these days but it wasn't always so.

That's actually quite interesting - I remember similar comments (Phd required, or Phds aren't able to understand it) cropping up in discussions of the GNU autotools toolchain. (With a fair bit if justification, in my own experience, although I understand the results tended to be better for those who were shell script gurus...)

Autotools is actually quite simple to understand.

If your install needs autotools, your install is broken. :)

The number of projects that need autotools in this day and age is vanishingly small. A small script (bash/python/perl/ruby) that checks exactly what you need and then runs make instead of copying 15 years of cargo cult m4 is far superior to autotools.

It gets much worse once you step out of the open source software and start up communities.

This is exactly what keeps me on Mercurial.

I can teach Mercurial to CEO's, artists, students, etc. and some of them will be better than me on it with a week or two. All of them "get it" and it's "low friction"--they can commit and forget about it. People who need it can handle merging and the rest can ignore it. People who need branches can use it and the rest can ignore it. etc.

git doesn't allow this. git is all or nothing. Either you inload the whole mental model, or you WILL wedge your repository somehow when you execute a command that doesn't quite do what you think it does. At that point, you will spend 4 hours combing Stack Overflow for the answer. Or you will just pull up the filesystem copy of the git repo you made before executing any command other than "git pull" or "git clone".