[PATCH RFC] revert: add --force option

Jesse Glick jesse.glick at oracle.com
Thu Jul 21 11:10:34 CDT 2011


On 06/06/2011 03:53 PM, Matt Mackall wrote:
> 'hg revert -a -r .' is actually fairly common for doing dummy merges.
>
> And -a is already our 'force' switch for this command.

Not exactly; prior to 1.9, you had to (a) pass either -a or some files, (b) and pass '-r .'. Now as of afe0d4c24866 someone with a weak grasp on what they are doing can run

$ hg merge
merging my-stuff/f1
warning: conflicts during merge.
merging my-stuff/f1 failed!
$ # oops...
$ vi my-stuff/f1
$ hg res -m my-stuff/f1
$ hg st
M my-stuff/f1
M subdir-I-never-touched/f2
$ # huh, why is that other stuff modified?
$ hg di
...lots of changes I know nothing about...
$ # looks bad, I did not want to make all those changes
$ hg revert subdir-I-never-touched
(silent)
$ hg di
...just stuff I work on...
$ # whew!
$ hg ci -m merged

and produce a bogus merge backing out unrelated changes... which is then hard to detect and even harder to correct, much much worse than leaving a non-merge working copy 
with odd modifications. (See #981, #1010, #1038.)

At least before, they would get an error message and be forced to pass '-r .' and maybe think for a moment about what that would mean (or ask someone for help).

If anything, I would recommend that revert (with any options) on an uncommitted merge should print a strict warning that this command may be leading up to a bad merge. 
Anything to convince novices not to go ahead and commit, unless they really understand merges and wanted to do this. Far better to sound condescending than to silently 
let new users make grave errors and be made to feel later that it is their fault.

(In my ideal world, 'hg merge' and other commands that do merges would automatically commit the merge changeset right away, using a noninteractive conflict resolution 
algorithm, so you would never have a working copy with two parents. If there were any conflict markers or similar mistakes, they would be reported as warnings and you 
would clean them up in a separate regular commit afterwards where diff, stat, etc. have their normal meanings. Such a change would make Hg much safer, I think.)



More information about the Mercurial-devel mailing list