"hg up -C" is also evil - ;-)

[Robert Figura]

Waldemar <waldemar at beechwoods.com> wrote:
> On 11/05/2010 07:55 AM, Kevin Bullock wrote:
> > On 5 Nov 2010, at 7:12 AM, Marko Käning wrote:

> >> Yesterday I issued the command
> >>
> >> 	$ hg up -C
> >>
> >> actually believing that local changes would be moved into *.orig prior to 
> >> the clean update of my working copy.
> >>
> >> But I was wrong! In many other cases local changes will be preserved with 
> >> *.orig files or additional warning messages will be thrown, but obviously 
> >> not with a clean update...
> >>     
> > -C == --clean, which would indicate to me that any uncommitted work will at least be at _risk_ of disappearing. It would seem to make sense to write *.orig files though.

Two things come to my mind:
1. Your proposal sounds consistent to me as hg up -C would not
remove .orig (or other unknown) files...
2. But as hg up is a very common command i see me removing heaps of
unwanted files all day.

> I think what's missing is a really solid integration with "shelve".   In
> case of hg update, working directory should ideally be stored in some
> orderly manner with a chance of quick restoration with a single
> command.  For me it's the "third level" of source control. After
> traditional versioning, mq patches, this would be workdir management.

Let me imagine. Any command causing an effect on uncommitted changes
stores the original files in an undo record. There'd also be the command
which caused that backupset and the previous `hg id` which might be
worth recording. 
- I like that .orig files are easily accessed (mostly diff and copy
  though).
- Using undo on mq revs you could still lose workdir states...

Right now i'm quite happy with my habit to make "temporary" commits in
case i feel any doubts and pushing to an attic before stripping
anything.

Just my 0.epsilon cents, kind regards
  - Robert Figura

-- 
http://teslawm.org/