Given how many smart people are confused by Git, and how many times Git's behavior needs to be explained in a way that often raises as many questions as it answers, it seems to indicate that Git's model is not at all intuitive and doesn't map well to how people generally use it to get work done.
These are all people who have no problem understanding all kinds of other technologies and building complex systems from them.
It's not quite in "a monad is just a monoid in the category of endofunctors" territory, but when this many smart people have difficulty understanding something, I think Git is to blame, not the people.
I have to serious ask. Of the people who have issues with using or understanding git, how many of them have actually read the docs?
Git is by no means perfect but the development community is great and there is a massive focus on improving the project and making things more approachable and intuitive.
And because of that, git actually has really solid, coherent documentation with easily digestible tutorials and guides for all the things you need to do.
So it always hurts me when I see people ranting and raving about how awful git is, how it can't do x, or how it doesn't make sense how it works but then you send them the guide or tutorial hosted on the git-scm website and suddenly it makes sense.
Git makes version control roughly 10x more complicated than it needs to be.
I can teach an artist or designer who has never heard of version control how to use Perforce in roughly 5 minutes. They will never blow off their leg and will likely never lose work. It will probably be a few months before they hit some edge case where they need help.
Git requires building a non-trivial mental model. Then it requires memorizing a whole bunch of unintuitive commands with unintuitive flags.
> Not to be beating the RTFM horse but RTFM guys.
Good tools are intuitive and can be incrementally learned without resorting to dense documentation.
RTFM is definitely a solution. But when a very large number of users have consistently similar issues at some point you have to stop blaming the users and admit the tool isn't easy to learn.
Part of the problem with teaching Git, aside from the terrible interface design, is probably that programmers are the ones teaching it. This is very nearly indisputable/self-evident. Look at the Git man pages. (NB: Documentation falls under the umbrella of "teaching".)
I went to a short, semi-casual digitization symposium. It was a couple hours long with a handful of lightning talks and a keynote. All the presenters were researchers in the humanities versed in the subject matter of e.g. library science. I later learned that the university had recently introduced an "open source program office" that's supposed to be a resource for crossing the discipline divide. The idea is that the progress that the world of software development is making should leak into other disciplines to the extent that it can be helpful. There's a course in the School of Information taught by a programmer that tries to do something similar: people with domain expertise are supposed to take the course to pick up a little bit of programming and get exposure to Git to help with e.g. data science projects.
In thinking about how the material would hypothetically be presented to these folks, I realized that the humanities folks in particular were uniquely positioned to be able to grok Git the best—almost certainly better at grasping the underlying fundamentals than, say, a group of freshman programmers with no experience with version control, Git or otherwise. Programmers lack the foundation and interest in the underlying discipline.
> Git makes version control roughly 10x more complicated than it needs to be.
A significant part of this is that git explicitly supports more workflows than centralised VCS like subversion, perforce, or clearcase. Other than a few fairly small differences, mercurial and fossil (two other distributed VCS projects) have the same UX issues. You can't really reduce the complexity without just lopping off support. You can make that complexity more approachable/digestible (which the git devs are trying to do) but this fundamentally requires a certain willingness from the user to learn the tool.
For a lot of people git ends up being a sort of cargo cult where they get through the day with a set of magical incantations that make it work and solve their problems but without any real ability to troubleshoot when they do something wrong. Which is exactly the thing that prevents them from "gitting it".
And worth noting: I don't think I've ever worked with someone who has really gotten irreparably stuck with git after reading through the important parts of the user manual (not the references/man pages but the dedicated user manual [1]) and/or the git book [2]. There are some overly technical parts but they are towards the end of each. But if someone actually reads the entry-level user oriented parts of each/either document, odds are they'll understand enough to be able to actually solve their problems.
> A significant part of this is that git explicitly supports more workflows than centralised VCS like subversion, perforce, or clearcase.
I don't think this is quite correct. Mercurial is just as capable but has a much more accessible CLI.
Git pushes edge-cases to front and center. Almost all Git users use Git as a defacto centralized tool. There's a remote on GitHub, the end. Almost all users never need any feature that has to do with decentralization.
Git has somehow tricked people into thinking that version control is complicated. It's tragic.
Whenever I read the Git docs, after a while I start thinking "this is all very well and good, but it doesn't seem to be related to what I'm trying to do to get my work done (usually fairly basic things)"
Or I have read a bunch of pages on the git-scm site, and I'm thinking "oh yes it all makes sense now." Then I'm trying to do something in the real world, and I get bizarre messages and conflicts that don't make any sense. Or I made a mistake and want to undo it, and end up in some crazy situation. The Documentation doesn't seem to help in anything but an ideal textbook scenario with no mistakes and complications.
These are all people who have no problem understanding all kinds of other technologies and building complex systems from them.
It's not quite in "a monad is just a monoid in the category of endofunctors" territory, but when this many smart people have difficulty understanding something, I think Git is to blame, not the people.