warning message when adding large files

[Cathy Riemer]

On Sat, Apr 02, 2011 at 07:21:31PM +0200, Martin Geisler wrote:
> 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

I don't understand.  Doing forget without mv is the same as doing
forget with mv?  Why is that bad?  Or do you mean that forget
actually performs the mv itself, behind the scenes?  That does seem
bad -- what if I already had a working file called x.bak?

> 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.

Ouch -- yes, I am surprised!  I would expect x to be untouched in other
working copies, and just to get status '?' since it is now untracked.

These things need to be explained in 'hg help forget', IMHO.