https://bz.mercurial-scm.org/show_bug.cgi?id=5977
Bug ID: 5977 Summary: Uncommit should require -f/--force when possibly hiding data Product: Mercurial Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: feature Priority: wish Component: evolution Assignee: bugzi...@mercurial-scm.org Reporter: dan...@gmail.com CC: mercurial-devel@mercurial-scm.org, pierre-yves.da...@ens-lyon.org In a clean checkout, uncommit is quite safe and straightforward; you have data in your working directory, and do the opposite of commit/amend to get it ‘out’ of the repository rather than in. Good! With a dirty working copy, however, the behaviour might be somewhat confusing to a new user. Although by design, ‘uncommit’ never actually destroys data, it can hide it. Uncommit seems such a simple command that it should be possible to use and rely on it without actually understanding about obsolescence. The point isn't that uncommit destroys anything — the point is that it's such a simple command, unlike, say, prune, that user needn't actually understand obsolescence to use it. In the following workflow: $ hg init xxx $ cd xxx $ echo 'super critical info!' > A $ hg ci -A A -m A $ echo 42 > A $ hg unc A After the final line, the only way to obtain the critical info is using the --hidden flag. I'd propose something the following error message instead: $ hg unc A abort: uncommitted changes (use -f/--force to proceed) The -f/--force would exist for precisely this case — and please note that I haven't researched whether the error message is consistent with anything else. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel