[petercooper]

Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO.

This is a common problem in teaching, technical writing, and other forms of technical instruction.

Even when a good teacher or writer sets out to deliver material to total beginners, it's very tricky to truly enter the beginner's mindset and cast away a lot of the mental abstractions built up over the years.

I think one way to improve this situation is to focus on results and casually use features and techniques along the way rather than focus on features and techniques and have contrived examples to show off them off. The fewer technical terms or domain specific language you can use up front, the better. (I should note I've been very guilty of the contrived example approach, but this is what it's all about.. experimenting and learning what really works for learners :-))

[FrojoS]

I think one way to improve this situation is to focus on results and casually use features and techniques along the way rather than focus on features and techniques and have contrived examples to show off them off.

Yes, exactly! You have to start with examples. Real problems and then suggest solutions. Too many teachers, I'd say the majority, start from the abstract explanation and only bring in the example in the end -if at all.

[obtu]

This isn't necessarily a problem. I can learn by immersion.

Good teaching shouldn't introduce too many concepts at one time, but giving incremental goals that require interacting with a few related concepts is ideal. Tediously spelling out all the details is good for a spec, but would hurt interest and motivation.