The idea of a directed graph of file system snapshots is pretty intuitive. Add in branches as pointers to locations in that graph. This is a fantastic model for source control.
However the operations that stage a potential update to the graph of snapshots is prettt confusing. The "index" is a terrible name that is overloaded with so many other non-git meanings, non of which really map to git usage.
That, and all the rest of the names are pretty hard to understand. Particularly reset, whose documentation is inscrutable without translation from git-speak into technical language, or at least a dictionary of what all those words that are used actually mean. And since reset is such a useful tool and has about eleventy different functions, it all becomes impossible to learn from the docs on your own.
The well-documented underlying model used to confuse me a lot - especially for operations like merging, rebasing (squash, reorder, ...), cherry picking, etc. They started to make sense only when I realized that git uses diffs/patches to propagate changes between unrelated commits. While the on-disk format is purely snapshot-based, the tool itself is a hybrid. As far as I can tell, this trips up a lot of others too.
Even the operations which do show will often require more thought to undo than a hypothetical "git undo" would. I know how to use the reflog but I often go out of my way to avoid it because "git branch tmp HEAD; git $POSSIBLE_MISTAKE; git reset ---hard tmp; git branch -D tmp" requires less effort than deciphering the reflog's output.
Undoing a push does require a different set of commands, but my point, to the question @amelius asked, is that you can undo both push and add, and whatever other mistake you’re thinking of, difficult or not.
Git, coincidentally, does have something equivalent to undo history: the reflog.
git reset HEAD~1
Usually works good enough for me. Idk if this is the proposed way to undo stuffI doubt that was the intention. Linux just needed a versioning system tailored to its needs, and that's exactly what Git is. Can't blame its creators that other people used it for scenarios it wasn't built for.
This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software.
Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it.
It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work.
It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude.
Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.
(FWIW, I don't consider git complicated and I'm far from a power user)