Git has a very clean and simple data model. Unfortunately, this nice model often has very little bearing on how the `git` CLI works; it often takes things that should be simple operations and confuses or complicates them in various ways.

For example, say you’ve just made a commit, and then realized that wasn’t what you wanted to do so now you want to undo it. This can be described under git’s data model as “set the current branch to HEAD^ and discard the orphaned commit, leaving the working tree alone.” For some reason this is a “reset” operation (the same command you’d use to unstage a file, an otherwise unrelated operation) and you have to decide if you want to do a “hard,” “soft,” or “mixed” reset. If you get it wrong you’ll have to go grovelling in the reflog to get your files back.

To be fair, this situation is improving; the recent introduction of the switch and restore subcommands has helped to disentangle the especially overloaded checkout and reset subcommands, for example. But it’s still harder than it should be to convert a mental image of what you want done into the appropriate (series of) git commands, and vice versa.

The philosophy of git is fantastic, it is its unending collection of quirks, footguns, and inconsistencies that irritate people.