Just because something is conceptually simple does not make it simple to use. Similarly pointers are simple. They are things (usually variables) used to point to other things in memory by storing the memory address of the target. They are simple. And yet their usage is very complex.

Ridiculous, as in, a case where we actually need it is rare enough that by the time the need arises, everyone's forgotten how it works.

We're not in a shop where one-off merge commits are a thing anyone really cares about, so rebases usually mean things like "Somebody used the wrong committer name" or "Somebody did a branch merge incorrectly and now the history makes no sense".

The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

(1): The, IMO, canonical example for awful documentation design - why does a user credential switching program open with a primer to EBNF when it's hardly necessary?

> The git manpages suffer from the same problem as the sudo manpage(1). I want to know how to do "X" and why it works that way, and perhaps see examples explained.

Perhaps that's might apply to some git manpages, but man git-rebase in particular is really good. It has exactly what you want, example situations, the command lines to achieve them, complete with pretty ascii art diagrams.

It could still be improved, though. There might be some "oops I screwed up, what next" situations too. I think `git rebase --abort` works most of the time these days but it wasn't always so.