Understanding rebase --abort

[John W]

This might just be a documentation issue (or a me-being-thick issue),
but figured I'd ask:

How exactly is "rebase --abort" meant to behave?

The commandline docs say merely: "abort an interrupted rebase"
The wiki[1] says: "An interrupted process can be aborted, thus
restoring the repository to its original state..."

And it's that phrase "restoring the repository to its original state"
that doesn't quite match up to reality, in my experience.

Small example:

$ hg ini rebase-abort
$ cd rebase-abort
$ echo "initial data" > foo.txt
$ hg add
$ hg ci -m "initial checkin"
$ echo "change 1" > foo.txt
$ hg ci -m "change 1"
$ hg up 0
$ echo "conflicting change 1" > foo.txt
$ hg ci -m "conflicting 1"
$ echo "conflicting change 2" > foo.txt
$ hg ci -m "conflicting 2"
# About to rebase, so lets see where we are beforehand.
$ hg resolve -l
# Note: empty output - no merge in progress (as we would expect).
# Also, you can look at 'hg log -G' to see the state of things.
# Now do the rebase, forcing failure (would fail anyway, due to conflicts):
$ hg rebase -d 1 --tool 'internal:fail'
$ hg rebase --abort
$ hg resolve -l
U foo.txt
# Note: we seem to still be in a merge, even though we ran "rebase --abort".
# You can see this in 'hg log -G', too - two '@' marks.
# Also weird to me is this:
$ hg status
M foo.txt
# According to that, foo.txt is modified...
$ hg diff
# Empty output. So there is no actual modification. Disagrees with
what 'status' is saying.


Maybe it is a bug, or maybe docs need an update?
I'm trying to build a tool on top of rebase, so it would be nice to
understand what it's supposed to be doing, here.

Thanks
-John

[1] http://mercurial.selenic.com/wiki/RebaseExtension#Abort