warning message when adding large files

[Martin Geisler]

Cathy Riemer <cathy+hglist at bx.psu.edu> writes:

> On Fri, Apr 01, 2011 at 12:37:54PM +0200, Martin Geisler wrote:
>> timeless <timeless at gmail.com> writes:
>> 
>> > On Thu, Mar 31, 2011 at 9:08 PM, Matt Mackall <mpm at selenic.com> wrote:
>> >>> I don't understand why it suggests using "revert".  Shouldn't
>> >>> that be "forget"?
>> >>
>> >> They'll both give the same result, moving the file from added to
>> >> unknown.
>> >
>> > Offhand, I think i'd like to see us use 'forget' in this message.
>> 
>> I like revert since it might remind people that 'hg revert' is how
>> you remove lines from the output of 'hg status':
>> 
>>   $ hg status
>>   M a
>>   ! b
>>   R c
>>   $ hg revert a b c
>>   $ hg status
>> 
>> That is not true for 'hg forget' which wont restore deleted files or
>> revert modified files.
>
> But I was adding *new* files (and I imagine that is the usual case
> when this message is encountered). I think at least part of the
> problem lies in the documentation.

With a new file 'hg revert' brings the status back to '?' since the file
is untracked. That is the state it had before 'hg add'.

> "hg help revert" notes that "This command is most likely not
> what you are looking for", and says that it "modifies the working
> directory" and will "revert the named files or directories to
> the contents they had in the parent of the working directory".
> Since I was adding new files, this could mean that my working
> copies would get deleted to match the parent.  I did not want to
> modify the working directory, just unschedule the pending adds.
>
> In contrast, "hg help add" suggests using forget to undo it,
> and "hg help forget" sounds like just what I wanted.

Okay, and it was the command you wanted in this case. I'm not a big fan
of 'hg forget', though, since 'hg forget x' does the same as

  $ mv x x.bak
  $ hg forget x
  $ mv x.bak x

The fact that x is really deleted tends to surprise some people who
expect to be able to do 'hg forget x', without x being deleted from
other working copies that get the changeset.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110402/d671ee2b/attachment.pgp>