[ntobjx]

It works until it doesn't. One of the biggest problems with Git IMO is that it always exposed a plethora of internals which therefore have become public interfaces. One is to be expected to know the guts of .git as an intermediate/advanced user. And because those are interfaces, it's _always_ going to be very difficult to fix issues arising from previous wrong design decisions.

Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll get by with a dozen or so command line invocations overall. And I found it astonishing and disheartening how so many people were able to make do with completely illogical commands like "git checkout -b" ...

But once Git sticks you the finger and you _need_ to delve down into its guts, you often have a problem.

Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and web interfaces like GitHub glossing over numerous shortcomings of Git have certainly helped the UX and the popularity. But once you _have to_ delve down to CLI usage because you ran into an issue that your tool tries to gloss over, most people are at a loss. And most people will opt to scrap the current clone+worktree and clone anew. That doesn't really sound to me like people are in command of their tool of choice (Git), though.

And at this point we haven't even touched stuff like refs which only differ in case. It's all fine until Git starts unpacking the refs. Which can be fun on systems like macOS and Windows which have support for case-sensitivity in the file system, but who opted to forgo that via a setting.