Bug 3423 - hg forget followed by hg revert destroys local modifications
Summary: hg forget followed by hg revert destroys local modifications
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Kevin Bullock
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-03 20:28 UTC by Ben Boeckel
Modified: 2013-11-07 17:35 UTC (History)
7 users (show)

See Also:
Python Version: ---


Attachments
(34 bytes, text/x-sh)
2012-05-03 20:28 UTC, Ben Boeckel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Boeckel 2012-05-03 20:28 UTC
When a file contains untracked changes that are 'staged' and then hg forget 
followed by hg revert is done on the file, any untracked changes are blown 
away. Reproducer script attached.

Version: 2.2
Comment 1 David M. Carr 2012-05-03 23:03 UTC
If I'm understanding correctly, your expectation was that the "hg revert" 
would create a backup file for the removed file.

"hg help revert" currently says "Modified files are saved with a .orig 
suffix before reverting."  My impression is that this means modified as 
reported by status.  Since the file in question had a "removed" status, it 
wasn't considered for backup.  To that extent, it sounds like it's working 
as intended.

However, it is somewhat odd that the combination of "hg forget" (a command 
that doesn't touch the working directory) and "hg revert" (a command that 
attempts to generally be "safe" by backing up modifications) results in file 
contents being lost without backup.
Comment 2 Martin Geisler 2012-05-04 01:19 UTC
Let me inline the test script so that we can better see what we're talking
about:

  hg init
  touch empty
  hg add empty
  hg commit -m 'commit'
  echo 'a difference' > empty
  hg forget empty
  hg revert empty

The empty file is now empty again (as it should be), but there's no backup made.
Comment 3 Kevin Bullock 2012-05-04 08:01 UTC
Note that the antonym of 'hg forget' is 'hg add', NOT 'hg revert'.

Keeping a .orig if a forgotten file being reverted differs from the file on 
disk would probably be a good thing though. All that should be required is to 
add a check when reverting a file that's 'R'emoved in dirstate: if the file 
exists on disk, make a backup.

Downgrading to 'bug'.
Comment 4 RonnyPfannschmidt 2012-05-04 08:15 UTC
i think revert should make backups of all files it overwrites,
not just those having some state in dirstate
Comment 5 Ben Boeckel 2012-05-04 09:19 UTC
@krbullock: I suppose some more context would be helpful.

I made some changes to the repository, but the hg add had added too much to 
the 'index'. I tried hg forget, but ended up forgetting an entire directory. 
Here, as a git user, I expected it to only 'unstage' things that I had added 
for committing (but now, ISTR that hg doesn't actually have an index per sé, 
so this is probably where my confusion went really wrong). In order to get 
the files back from the forget, I did an hg revert to get rid of the 'R' 
status on all of the files.

My git-fu is probably making me expect odd things (hg certainly feels like 
some foreign dialect of git where verbs mean similar-but-not-quite the same 
thing), but the main issue I see is that my changes were lost without backup 
or notification (which, IMO, should happen whenever a backup is made with hg 
revert). From my experience with git, hg forget feels like it should error 
that you're forgetting changes not in the repository and require -f to do 
so.
Comment 6 Bugzilla 2012-05-12 09:30 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:30 EDT  ---

This bug was previously known as _bug_ 3422 at http://mercurial.selenic.com/bts/issue3422
Imported an attachment (id=1657)
Comment 7 HG Bot 2013-07-26 19:00 UTC
Fixed by http://selenic.com/repo/hg/rev/8b190adb7ee3
Matt Mackall <mpm@selenic.com>
revert: make backup when unforgetting a file (issue3423)

This skips the backup if it would be a duplicate.

(please test the fix)
Comment 8 Ben Boeckel 2013-07-26 19:28 UTC
Thanks for the fix; I'll try to test this weekend.