The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.
Think of it like the difference between learning how an engine works, and learning how [some particular engine, in some particular car] works. The first is pretty simple and illuminating. The second has lots of annoying details and imperfections. If you want to work with cars, you learn the former first.
See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...
While true, there's also a category of git users who are no longer really "newcomers" but still use git primarily as a subversion emulator and want to learn more.
I'd love to see your notes.
I found that when I was learning git there were two concepts that were crucial: understanding the staging area, and understanding the very basics of the DAG (not talking about tree objects, only spending just enough time to learn how to merge and rebase).
I have to say I was a little disappointed this tutorial didn't even mention the word staging, since it's pretty important to being able to use the interface.
1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add)
2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.
Both equally fail at making people get git.
Having explained git an inordinate number of times to various people, I started writing here all I ever needed to introduce people to git in a few minutes†, but it takes longer to write than to explain hands-on and face to face. I'll complete this and make a gist out of it.
† For varying definitions of "few" and possibly "minutes", but honestly much less than people make it sound about git being a horrendous, unlearnable, complex system with a broken UI. It's simple, it's brilliant, you just have to set the bar right in between 1. and 2. when teaching it.