`histedit` does what `rebase -i` does, `hg rebase` does what `rebase` does.
There are a few limitations to `histedit` compared to `git rebase -i` I think: I believe it's possible to split revisions using `rebase -i`, I don't think that can be done using histedit (it has pick, edit, drop and fold). Histedit also misses the (pretty recent I believe) `exec` action of git's rebase -i.
hg branches are entirely different from git branches, so resetting them in that way doesn't make sense. The closest approximation - bookmarks - can indeed be reset (hg bookmark -f).
histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
Hg seems to have evolved several vaguely similar but isolated optional features (named branches, local branches, bookmarks, patch queues) which I guess means they haven't arrived at one everybody's happy with. Some people even prefer to keep hg branches in cloned repos, which sounds very painful. Git handles all those use cases by binding a ref to a commit and calling it a branch (even stashes are stored as branches, just more difficult to push).
> histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
That is correct. In Mercurial, git's `rebase` is (sensibly, as far as I am concerned) split into two different commands: `histedit` handles the history edition within a branch and `rebase` handles the rebasing of a branch on a revision of an other branch.
Can hg set the current branch to point anywhere in time?
Does histedit do exactly what "rebase" does? Does it also work with "--onto" and other rebase features?