After the discussion on the list about hg revert -i, it seems like we are
satisfied with what we called proposition 2. It shows the changes to revert in
the same direction as hg diff. This patch makes it the default option.
It changes all the + in - and vice versa in the tests for revert -i.
Currently we are handling editing of newly-added files with the interactive
interface. We are not handling editing of deleted files. In the test for revert,
we were editing a newly-added file. Since we want to change the direction of
revert -i, this editing of a newly-added file will become editing of a deleted file.
Since we don't support that, this patch changes the test to make the rest of
the series cleaner.
We had a discussion on the list about the interactive ui for revert. This patch
adds a flag to allow people to test the second alternative (referred to as
proposition 2 on the mailing list). It effectively inverts the signs in the
Before this patch: editing hunks of newly added file when performing a revert
--interactive had no effect: the edits were discarded.
After this patch, the edits are taken into account.
This allows us to use existing code to detect files that are newly added and
modified. In turn, this allows us to make revert --interactive support
editing newly added and modified files.
The '--all' option have been introduced in 0a81b7721d8f (August 2006), most
probably to prevent user shooting themselves in the foot. As the record process
will let you, view and select the set of files and change you want to revert, I
feel like the '--all' flag is superfluous in the '--interactive' case.
The seq.py and shell echo redirected to a file ends up with platform
specific EOL, which throws off the hash when the file is committed to
the test repo on Windows. The other option is to glob the hashes, but
the ability to see if they have changed might point out problems that
would otherwise be missed.