You don't need to learn its internals or read its code. You do need to learn what it does. This is not unreasonable, and is not the reason its interface is a mess.

Previous poster literally writes about implementation details.

>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

Blobs, trees, commits, refs, and index are not "internals" or "implementation details", they are the domain.

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.

These aren't implementation details, these are the things you are actually dealing with when you use git.

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.

For a "normal" use case one can get away with just git clone, git checkout, git add, git commit, git push, git pull. Anything more advanced like rebasing onto master and squashing before merging (unfortunately) demands that one has at least understanding of git objects. I’ve also noticed the reverse is true - the more understanding of git objects one has, the less catastrophic/unexpected situations ones finds itself into.

git gets the "holy pass" because it was created by Saviour Linus Torvalds and thus to question it is Heresy. If you don't git it, it's because the problem is with you, never with git. Learn To Git, boy.