stymied by default update

[Matt Harbison]

On Tue, 30 Dec 2014 21:26:02 -0500, John Turner <jjturner at energi.com>  
wrote:

> On Tue, 30 Dec 2014 18:02:02 -0500, Matt Mackall <mpm at selenic.com> wrote:
>
>> On Tue, 2014-12-30 at 17:44 -0500, John Turner wrote:
>>> On Tue, 30 Dec 2014 17:37:11 -0500, John Turner <jjturner at energi.com>
>>> wrote:
>>>
>>> > Greetings,
>>> >
>>> > Still learning the ropes here -
>>> > 1) the head commit to my new repo was an add of 655 files
>>
>> We call this the root. Heads are on the other end of history.
>
> Apologies for the faulty nomenclature, for some reason I had it in my  
> mind that head and tip were opposites.  There may have been an extant  
> online tutorial I read too quickly.. at any rate 'root' is certainly  
> unambiguous.
>
>
>> Ignore patterns sole reason for existence is to decide which UNKNOWN
>> files are not interesting. Known, tracked files are interesting by
>> definition, so we don't ignore them. Every SCM I'm aware of works this
>> way.
>
> As a novice, I've already managed to gum up a couple of my repos with  
> the 'uninteresting' files, so it's been a bit of back-and-forth exercise  
> to strain out the wheat from the chaff :) - I only alluded to my ignore  
> setup thinking that may somehow be playing a role in this odd situation,  
> but it looks to be more of a red herring in light of the null parent  
> reference below.
>
>>> As a reference, here is the log (the "-1:000000000000" seems to be  
>>> telling
>>> me something..):
>>> E:\rmat_app>hg log
>>> changeset:   3:30cf64386e8d
>>> tag:         tip
>>> user:        jt
>>> date:        Tue Dec 30 17:26:30 2014 -0500
>>> summary:     reverting to just ignore of .rpt files
>>>
>>> changeset:   2:cce500291c6a
>>> user:        jt
>>> date:        Tue Dec 30 14:58:49 2014 -0500
>>> summary:     ignoring anything in reports\base folder
>>>
>>> changeset:   1:001d10e9ced9
>>> parent:      -1:000000000000
>>> user:        jt
>>> date:        Tue Dec 30 13:45:37 2014 -0500
>>> summary:     adding 5 files at repo root
>>
>> When you did this commit, you had nothing (aka -1 aka 000000 aka null)
>> checked out. Perhaps you did:
>>
>> $ hg init repo2 # empty repo with null checked out
>> $ cd b
>> $ hg pull path-to-repo1 # push/pull does not affect check-out
>>
>
> Ah, I think I see the rookie mistake (for the record, I wasn't working  
> with any other repo) --
> I've gotten into the (bad?) habit of running:
> $ hg update null
>
> .. I suppose for the sake of starting from a clean slate in the working  
> directory.

If by clean you mean "get rid of uncommitted changes", look at 'hg update  
--clean .'  The only time I've ever updated to null is to completely  
remove the working directory files from the file system, but that is very  
rare.  Updating to something other than '.' is also going to change the  
parent revision, unless that something is the equivalent revision, hash,  
tag, etc.  That seems to be where you went wrong.

> I believe that was the state prior to my adding and committing the 5  
> files for changeset 1.
>
> So the null parent makes sense in that case - but if so, how to  
> 'recover' the root changeset which still holds my 655 files?

I'm guessing your files live in rev 0, since I don't see them in the log  
output.  Try 'hg update 0'.  You should probably change your habit from  
using 'null', to the revision number where you want to go.  Once you get  
comfortable with the command line and your repositories, you can start  
using revsets instead of having to look up the revision number you want  
first.

--Matt