git revert doesn't undo a commit though— it creates a new commit that undoes it. That might be what you want under some circumstances, but most of the time that I want to revert it's a commit I just made and haven't pushed yet, so I just want to pretend it never existed.
I never want that though. If I wanted to do something like that, I'd do the git reset soft, followed by git stash, followed by git switch. I think this at least allows me to look back at it locally?
Git switch is also something I learned recently so sometimes I type checkout because of force of habit but I am trying to do better (even though I'm not sure what switch dies that checkout can't but don't want to get into arguments, just want to do things the prescribed way).
The thing about git is that it's basically plumbing all the way down. In this case: switch abstracts over checkout, which abstracts over read-tree & checkout-index. The nesting doll just keeps going.
Because switch is built on top of checkout, there's no functional difference between the output of the two subcommands when used for the same purpose (assuming the presence of a skilled operator). It's strictly a matter of ergonomics and abstraction.
At the end of the day, as long as you don't fuck up, just do whatever best keeps you in your flow state.
What's wrong with just working on and when the changes finally look like they should just do a `git commit --amend`?
Or if the commit should for some strange reasons really never exist just move HEAD one commit back. You could even get the changes back by merging the "bad" commit back without committing the merge (using the `--no-commit` switch).
Making committed history disappear isn't something I would call a "simple action". That's something that is almost never needed.
The common case it to amend mistakes. Git makes it very easy to accomplish that.
The other thing is: Git is conceptually very simple. There are almost no "esoteric" concepts. It's just a Merkle tree and some pointers to nodes on top of a very simple plain-text database.
My experience with people that have problems to understand Git is that most of the time those people never tried to understand how Git actually works. But everything (besides the concrete commands and switches, oc) becomes almost obvious when knowing the inner workings.
The main problem with Git is its UX.
I don't know anything of this stuff out of the top of my head! I have to look up the concrete commands or switches every time. But from the conceptual point of view Git is very easy to use. Because the underlying concepts are indeed so simple and straight forward.