I know the you (the reader) are probably tired of discussing how `hg
revert -i -r .` should behave and so am I. And I know I'm one of the
people who argued that showing the diff from the working copy to the
parent was confusing. I think it is less confusing now that we show
the diff from the parent to the working copy, but I still find it
confusing. I think showing the diff of hunks to keep might make it
easier to understand. So that's what this patch provides an option
for.
One argument doing it this way is that most people seem to find `hg
split` natural. I suspect that is because it shows the forward diff
(from parent commit to the commit) and asks you what to put in the
first commit. I think the new "keep" mode for revert (this patch)
matches that.
In "keep" mode, all the changes are still selected by default. That
means that hg revert -i followed by 'A' (keep all) (or 'c' in
curses) will be different from hg revert -a. That's mostly because
that was simplest. It can also be argued that it's safest. But it can
also be argued that it should be consistent with hg revert -a.
Note that in this mode, you can edit the hunks and it will do what you
expect (e.g. add new lines to your file if you added a new lines when
editing). The test case shows that that works.
Is there any reason for it to be experimental? I see hg revert -i is not interactive.