At the very least, from the top of my head: add, clone, checkout, diff, log, tag, show, status.

But it's not really about the number of subcommands, but rather how complex some of these subcommands are. e.g. git-commit(1) is 655 lines (and references other pages, too). hg's "help commit" is 59 lines, or 98 with --verbose (this also references some other pages, so it's not all you need, but it's indicative of the relative complexity).

Thats what 95% of people are doing with git but the fact that git has so much more complexity built into it to get to those simple operations is what the author is talking about. Although that tech is cool, it does have a lot of complications.

Anything more complex than the trivial pull/commit/push workflow forces you to google stackoverflow or read a long manual page for a command with tens of options, and the lingo there is full of weird stuff like “refspec”, “reflog” and “detached head”.

For worktree, what does this mean (in the docs)?

> Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.

I'm not quite sure what is safe and what is risky.

The rebase command hides a lot of complexity. You also left out merges.

undo commit