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.
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.