My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)

Reflog is, as the article says, the permission to do all kinds of crazy things, including rebasing. Once you realize any committed state is recoverable for a good period of time it really frees you.

Plus you can always take a note of the commit hash before you do anything crazy. But reflog means you don't have to.

Git really does have all the features you need. I wouldn't argue with anyone complaining about the UI to get there. But it's all in there somewhere.

When I interview someone and they are scared of `git rebase -i` it's a huge red flag.

Git rebase has such foundational data structures and concepts that you couldn't pass a serious college programming course without grokking it.

The only reason someone would be scared of git rebase is:

  a) they don't know the basics of programming/software engineering
  b) they are not intellectually curious enough to look into how tf the software they use every day works

This notion that `git rebase -i` is some scary unusual thing is totally alien to me. Doing some minor cleanup on local history with rebase is a *basic* operation that I would have thought everyone would be using regularly.

Correct on both counts.

The part where git needs to be “understood” is the entire problem. “Do one thing and do it well” was the whole mantra, which was completely ignored with the disaster that is git. It’s objectively awful.