> You can't learn Git by using its commands.

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.

> 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?

> 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.

Is there any other soft where ppl do seriously advise newbies to learn its internals?

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 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.

There are a couple of problems with this in my experience. People who have done computer science or systems/OS programming in a lower level language like C are really comfortable with concepts like pointers/references/links, objects, trees etc. But there are loads of programmers who don't speak this language at all. When I try to explain that almost everything is immutable and append-only and they are only mutating a single reference called HEAD it just doesn't make sense.

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.

How to waste a week without learning anything useful about actually using git :D

At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.