From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools.
Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.
I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense.
You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.
Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass"
Imagine having to read excel's or windows code in order to use it consciously, lol.
>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.
The other thing is, like you say, git itself is a terrible way to learn these concepts. A command line interface is great for expressing operations, but the state, before and after, is basically invisible. I think this might be especially hard for more visual people. When I was learning data structures drawing them out and "seeing" the structure was vitally important and I know it's not just me because computer science books are filled with pictures.
I really want there to be a GUI I can recommend people to use for git, but I'm not aware of a good one. I use magit which helps a lot, but I can't recommend that to most people. All the other GUIs I've seen are just about doing command line stuff with a mouse.
At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.