>You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared).
Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal
It's like how for a word processor the domain is text, et. al., or for e.g. Inkscape the domain is SVG.
Git has two levels, called "plumbing" and "porcelain" (I think.)
The "plumbing" (blobs, trees, commits, refs, and index) is elegant and easy to understand and use.
The "porcelain" is where everybody gets bogged down. I'll omit my own opinion (low) and just say that most of the problems people have with git seem to be related to trying to do complicated things with the crummy UX porcelain.
And that seems to be because they learned the porcelain but not the plumbing.
So what you're hearing is people advising people to learn the plumbing (as a side effect the porcelain becomes less unbearable.) In fact, if you know the plumbing you can write your own porcelain, and it's not hard and the code is brief because git is actually elegant and easy to understand and use.
You have to have some mental model of what the program is doing. With SVN it's basically "the server has the latest version, you can download or update that". With git it's "You have commits (snapshots of the whole state of your directory) which are addressable by the hash of that commit and refer back to previous commits. Also, here's a bunch of tools to manipulate and share that". The gp list of terms you should know is pretty close to just covering that.
For me I like git because it doesn't guess what I want to do, it give me tools to do what I want and then does what I tell it.