Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design.
Secondly, even programming language designers strive towards lowering this learning curve. There is, imo, a necessary complexity, or "table stakes" for any reasonably useful language, but its still very evident to any language designer that this is a trade-off. Usability is desirable.
For a tool as popular and essential as Git, usability should be a much more central goal than it seems to have been in the past.
Is writing programs and building them a part of your workflow? Do you even spend time on setting up your build? On acquiring an actual understanding of how it works?
Other tools are no different. If it's an important tool, it pays to actually study it. Do not expect tools to do what you mean before you know well what you mean.
I think you're misinterpreting my post. I completely agree, you're absolutely right, but there's a huge different between what you're saying and what the gp was: that usability should not be a consideration for these tools.
I do understand, in quite a bit of depth (which I'm sure is still far from complete), how Git works. I still prefer to use Mercurial because it doesn't require me to be continuously aware of the dangers of those internals on a day-to-day basis - it doesn't supply me with a loaded foot gun. Sadly, I use Git every day, and rarely Mercurial, because that's what the masses have chosen and I've found using in-between compat tools not to be worth the extra hassle for me.
OK, I can agree: git is not as safe, mistake-proof, or consistent as it could be.
What I like about git is that it gives a simple algebra of patches (diffs), and allows almost any sensible operation over them.
It would be great to build a different CLI on top of the same data structures (and maybe the same plumbing) that would expose a more consistent and usable interface, while allowing for [most of] the same capabilities, and preserving interoperability. I suppose git-hg tries to achieve something similar, too.
For me, much of the pain of git CLI was alleviated first by a set of aliases, and then by using magit from within emacs.
UI usability is irrelevant... ?!??
> isn't that how every programming tutorial works
Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design.
Secondly, even programming language designers strive towards lowering this learning curve. There is, imo, a necessary complexity, or "table stakes" for any reasonably useful language, but its still very evident to any language designer that this is a trade-off. Usability is desirable.
For a tool as popular and essential as Git, usability should be a much more central goal than it seems to have been in the past.