Yeah, I think this is the killer, and it's been my experience teaching Git to others. SVN does have a mental model that makes more sense: there's my copy, and there's the server copy. When I finish, I make the server copy look like mine. Done.

The terminology used by Git makes things hard for people to understand, remote and local, branches here there and everywhere. The OP is right that the deletion syntax for branches is awful.

BUT

It's not magic. It's explained all very easily.

"The staging area lets you batch up your changes so you can issue multiple commands to add files, or get rid of them if you change your mind."

"Just use `git pull`. If you don't know why you need to `fetch`, don't do it. Git pull is just like an SVN checkout."

"When you commit, you don't have to send it to other people, so your work can be in a broken state, and you won't break it for everyone else. When you're super happy with it, use `push` and it'll be visible to everyone."

These explanations get people who understand SVN to get Git, and they understand exactly what Git is providing over SVN. Once I use these explanations, people never seem to have problems.

What seems to keep happening is they look on the Internet for solutions to issues, which tangles them up even further, with rebasing and such. Even the simpler tutorials like learn.github.com are obsessed with showing pictures of trees and different branching states that beginners simply shouldn't be exposed to. Their mental model is completely screwed up, and they start to blame Git (not unreasonably) rather than themselves. When SVN screw ups happen, they blame themselves because SVN is conceptually simple, so they know the mistake must have happened with them. Then I hear things like "This never happened with SVN" or "SVN was always so much easier". When I prod them about this, they do end up remembering that SVN had it's own issues, but they forget them when their current problem is Git.

EDIT: Oh, and the other problem is that some of the GUIs out there are criminally poor. Particularly eGit for Eclipse. It exposes a metric crapton of functionality that I have absolutely no idea about, and I've been using Git happily for two or three years now. I don't know about refs or anything, and eGit makes it all exposed and seriously painful to do anything. Having tried to help someone with it, I gave up. "I use the command-line. You think I use it because I am clever, but I use it because I am stupid. The command-line is much simpler than this car crash, and I have no idea how you have got as far as you have with it."

This.

This is the key issue. I spent a year or two as a Git skeptic, but then I realised that git is the wrong answer only if the question is "What SCMs are out there that will magically improve version control while presenting me with an interface and workflow identical to SVN?"

> The hardest part is not learning "obscure" git things, it's unlearning the habits and preconceived ideas about how SCMs work.

I've begun to think of engineer's ability to "get Git" as a sort of abstract-thinking FizzBuzz. DVCS breaks up some composite actions (svn commit/checkout) into their component parts (git fetch/merge/commit/push). If you can't make that mental leap and see the value in it (and accompanying tradeoffs) despite all the learning materials out there, how can you be expected to derive comparable evolutions of design and engineer on your own?