I don't think this is really true.

Sure, you have to learn the (absurdly simple) model that git uses behind the scenes, but after you do that, who really cares about the standard CLI interface? That interface sucks in the same way a dashboard might suck on an all-terrian vehicle. Sure it looks like shit, all the knobs are in the wrong place and don't turn in consistent ways, and that analog clock seems really out of place in a car... but who really cares? It doesn't impede actual use.

Those "internal details of its implementation" are in fact what git actually is. "Learning git" without learning that stuff is not in fact learning git.

I agree with you, basically, but that is the substance of my complaint. Git leaves all of its messy internal bits exposed and does not provide a clean abstraction layer in its interface. Many people have written such abstraction layers, but they tend to be incomplete, and none of them is a standard. Everyone who wants to use git - which includes everyone who wants to merely collaborate with other people who use git - therefore has to learn git's internal implementation details.

It's one thing to learn the internal implementation details when you are a power user who really cares about a particular tool and wants to master it: it's another thing to require everyone to gain low-level familiarity.

The whole point of a computer - indeed, the whole point of computing, if you look at it through a lambda-calculus lens - is to provide abstractions over lower-level details, thereby allowing human brains to spend less time worrying about those details and more time manipulating higher-level abstract concepts.

In failing to offer a high-level interface, git wastes human brainpower which could otherwise be spent solving actual problems.

You don't need to know what an AST or a symbol table or an intermediate representation are to use gcc; you don't need to understand static single-assignment form, linker relocation entries, or ELF segments. You can use the tool without any knowledge of its internal mechanisms. This is not true of Git, and that is why I hope it can be improved or replaced with something that has more respect for human brain power.

I found learning git to be very similar to learning vim.

Nothing felt intuitive. The interface for vim might in fact be unintuitive and that might make learning it take longer.

But once you learn it, the un-intuitiveness is no longer a barrier.

I don't argue that learning git is difficult no matter what your background is. But that's the nature of a tool that's almost 100% un-opinionated on how you do something.

I don't disagree with your comment but I think that's inevitable for this type of tool.

I don't see how an unintuitive CLI is 'inevitable' or 'in the nature' of such a tool.

How is it inevitable to have inconsistant flags for showing contextual help?

How is it in the nature of such a tool to have command names that are inconsistant (for example 'push' to not be the opposite of 'pull')?

I think in the end these things are relatively small oversights by Torvalds at the beginning, that have become rather difficult to fix now, after git has become such a standard tool - but it makes live really hard for every beginner. I mean imagine a GUI application where the help menu is sometimes accessed through F1, sometimes it's shift-F3. Imagine Edit->Copy would do something completely different than what people are used to form other similar programs. Even worse, in a GUI tool it's no big deal to fix those problems in version 2, but a CLI automatically becomes an API for other higher level tools such as GitHub and changing it would break it afterwards - so it's really important to get that interface right from the start.

I've never found the inconsistencies in the API the major learning hurdle for git. If that's the case then it's really too bad since, as you mentioned, it could have been avoided.

For me the hurdle was not the API. That's what documentation is for. It makes learning it inefficient to always check the docs but that's about all.