I meant the tool-vs-internals idea, not the specific example here. If you want something comparable in complexity: we learn programming from `print "hello world"`, not from memory models and assembly. Some people even just start with `=sum(...)` in excel. Every programmer pretty much stops at the level that's useful and productive for them.

There's often sentiment that people should know more, but I don't think I've ever seen anyone saying starting programming from high level is "the wrong way".

Example from out of it: doctors learn both how to use USG and how it works. But in every case, I've seen it in that order: practice, then internals.

>we learn programming from `print "hello world"`, not from memory models and assembly

You're talking to the wrong crowd with me, you know. I disagree with this approach, too. Maybe we start with "hello world" to get a taste, but the first thing we should do is start breaking it down.

Thanks. I do understand where you're coming from - your original claim makes sense in that context :-)

You understand git. If someone said you need to know how sed works, or grep, or babel, or clang, or bash, or perl, or literally any other tool that you use regularly that you don't know the internals of then you'd quite reaaonably say they were wrong because you're an expert what matters to you and you can do your job without knowing how something else works. Perhaps you should try to respect that other people choose to become experts in things that aren't git.

If you use any of the tools listed, or any other tool, several times a day then it is reasonable to know the internals at least a bit. If you use grep (or git - the same applies) once a month then it's fine to just memorize some commands.

I don't think it's asking to have one's hand held to complain about git's poor interface. There's no reason other than lazy design to have a tool where to show all remotes it's

$ git remote -v

But to show all branches it's

$ git branch -a

It's like it's been purposefully designed to be obtuse.

It seems like you've made this example obtuse.

`git remote` and `git branch` list the remotes and branches respectively.

Adding -v makes both of these verbose. It will additionally show what each branch/remote is "pointing at".

Adding -a to `git branch` shows remote tracking branches in additional to local branches. This not normally interesting so the default is to list only local branches.

...yes, remote tracking branches are interesting as well, I don't know a situation where they wouldn't be.

There's plenty of weirdness in Git, but honestly my main complaint is that the interface is awful and the documentation makes Dostoyevski look modern and sleek.

You clearly have not ever worked on repos where nobody ever cleans up after themselves as far as feature branches go. I'm working with repos with remote branches numbering in the hundreds. `git branch -a` is pretty useless at this point unless paired with grep.

this is what I have my alias set to - `git branch -a --sort=-committerdate`

That's just by accident. There's plenty of obtuse git commands , strange command names, non-standardized parameters, etc.

We're all talking about learning the internals of git and how it works, not it's poorly formed command lines. Pointing out how shitty the interface can be doesn't mean you shouldn't learn how your tools work.

You say potato, I say potato. If the interface is clunky, you will learn by heart some switches and pass them on as cargo cult.

>We're all talking about learning the internals of git and how it works, not it's poorly formed command lines.

But the argument is being put forward that to understand the command lines you have to understand the internals.

Every other field makes damn sure that their tools are usable, comfortable and as safe as they can be. While programmers act like it's your fault if you hurt yourself while using a chainsaw-hammer.