Sometimes, it's really hard. Using the reflog is like looking through a pinhole.

When recovering from a bad merge conflict, you have a bunch of commits in your reflog which have the same name, and you need to decide which one you want. It's hard to look at the exact diff data and decide which one is appropriate.

It's not listed in the article, but it also enables a workflow where you check out parent commits many times along your branch of development and start new offshoots, and possibly amend commits with many descendants. It becomes nigh impossible to manage the reflog when there are so many commits with the same message but different content. The reflog itself also doesn't make it easy to recover lost descendant commits, only the given root commit.

Other scenarios: the reflog will not help recover where a deleted branch pointed to, and it won't help update multiple branches that pointed to the different positions in the same rebased stack of commits (the reflog for HEAD, anyways).

The complexity of executing a solution is irrelevant to the complexity of determining a solution. Regardless, you're being dismissive, and that attitude contributes to the unwillingness of people to ask questions, and therefore hinders learning on a large scale.

git reflog is hard enough so that I (a software engineer for 12 years and a git user for 10+ years) have to look up its syntax every time I need it.

I don't think the issue is so much that it's "hard" as that it's "not undo."

As a general rule of thumb, command line tools often ignore decades of UX best practice that have grown up. One of those is that operations (particularly destructive ones) should be easily reversible. It recognizes that human error is common.

And having "undo" specifically recognizes that human error puts the user in an emotional state where restoring things via complex operations is inviting risk. A typo to `git undo` is unlikely to be another command. A typo in the SHA (or an @{2} instead of an @{1}) for `git reset` will compound the error.

... that having been said, I'm going to go add `git undo` as an alias for `git reset HEAD@{1}` right now.

I know right? And a monad is just a monoid in the category of endofunctors. What's the problem?

I say code in my head when I’m thinking through how to approach something. Neither of those code snippets are smooth to recite for something that’s a fairly common operation.