The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite.

While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area at all.

Sure. I can get the same result I can get with simple staging with a complicated squash workflow. But why would I do that?

I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

> I have seen people get in trouble with rebasing and generally while manipulating history but never with the staging area.

I think that's what mercurial tries to solve, it makes manipulating history safe (by tracking the state of the commits, whether they were published or not for example, and always keeping all the history but hiding it after it was rewritten).

I should add. I always use a GUI like SourceTree for staging. With the command line it's much less fun.