hg update and deleted files

[Tom Karzes]

The problem with deleted files is that they result in your working copy
being out of sync with the parent change set, but they do not represent
uncommitted changes.  I.e. "hg commit" will ignore them since they have
not been scheduled for deletion.  But your working copy differs from
what it would be if you did a fresh clone.  Basically you want to "fix"
your working copy by restoring them.

I agree that ideally this case wouldn't arise, and that if people were
careful they would never delete files that are under revision control,
but it does happen sometimes, and it's nice to have a quick, safe way of
restoring them without having to think about it.  I sometimes see it
when I'm trying to help someone who's confused and has messed up their
working copy.  Typically the first thing I want to do is bring their
working copy up-to-date and restore any files they've deleted.  Then you
can run whatever tests are needed to decide whether to commit the
remaining changes.

Even if the commit is done first, and there are no remaining uncommitted
changes, I would still prefer to do "hg update" than "hg revert --all",
since the latter is dangerous and risks lost changes.

Tom


-----Original Message-----
From: Martin Geisler [mailto:mg at mgsys.dk] On Behalf Of Martin Geisler
Sent: Tuesday, June 22, 2010 4:37 PM
To: Haszlakiewicz, Eric
Cc: Tom Karzes; mercurial at selenic.com; Matt Mackall
Subject: Re: hg update and deleted files

"Haszlakiewicz, Eric" <EHASZLA at transunion.com> writes:

> On Behalf Of Martin Geisler
>>
>> I don't see why people should do that, I've certainly never felt a
>> need to write such a script. I just 'hg update -C .' if I need the
>> files back or I revert them. I also don't leave modified files lying
>> around in my working copy, which means that 'hg revert --all' does
>> work for me.
>
> Well some of us actually want to KEEP the changes we've been working
> on. A 'hg update -C' throws away *everything*! The expression throwing
> the baby out with the bath water seems rather appropriate here.

Then revert the files? How often do you go around and delete random
files anyway? :-)

I'm half-serious... I don't understand the workflow that makes you
update around so much, especially not with modified or deleted files in
your working copy.

>>> Something along those lines. It's a pain. Can't this just be added
>>> to "hg update" as the default behavior? It's consistent and
>>> symmetrical.
>>
>> I don't think adding an exception for missing files is consistent.
>> Letting Mercurial merge your modifications (modified and deleted
>> files) into the target revision is consistent.
>
> But those files are not actually deleted, not from hg's point of view!
> e.g. if you do "rm foo; hg ci -m blah; hg up null; hg up" the file
> comes right back.

Hmm, yeah, that is a funny corner case.

However, it follows the normal rules of always merging the working copy
changes into the target revision. Perhaps this shows it more clearly:

  % hg init
  % echo first > a.txt
  % hg add a.txt
  % hg commit -m 'first'
  % echo second >> a.txt
  % hg commit -m 'second'
  % echo first > a.txt
  % hg diff
  diff --git a/a.txt b/a.txt
  --- a/a.txt
  +++ b/a.txt
  @@ -1,2 +1,1 @@
   first
  -second
  % hg update 0
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  % hg diff
  % hg update
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  % cat a.txt
  first
  second

So when the merge is a no-op because the target revision already looks
like your modified working copy, well then this new state of
"unmodifiedness" will be preserved when you update.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/