Git is a rather beefy tool, boasting up to 150 subcommands, with the exact figure varying depending on the git version. Using the method from the thread on my machine:

$ git help -a | grep "^  " | wc -l
144

The 144 subcommands currently, however skewed the above metric might be, is still impressive. But I cannot say I like git. Sure, I use it almost every single day, even for tasks that are probably better handled by another tool, but still, it's a giant.

Subcommands are not the whole picture

You read that right and if you used git for just a little bit, you are probably aware of the fact, that basically all these subcommands have their own arguments and here's where all the chaos begins. I am not going to name them all, but you know I am talking about git add -A, git commit -a, git commit -m, git branch -r or git branch -m to name just a few.

So what's up with reset? Git reset is another such subcommands, that offer multiple arguments that are used really often. Specifically it is git reset --hard, that I think about as a kind of time machine for traveling back in time (in a commit history sort of time) and git reset --soft that I found myself using usually after some bad amend. Your mileage may vary.

Anyway, both these commands stem from their parent, the mighty git reset. How come I never used this command without arguments before? It is such a basic command, tied to the very core of the git itself. Well I finally crossed this line too. I successfully used (and understood) git reset to split previous commit into two separate ones! It really feels as ticking just another box in the programmers lifelong TODO list.