stymied by default update

John Turner jjturner at energi.com
Wed Dec 31 04:16:48 UTC 2014


On Tue, 30 Dec 2014 22:00:21 -0500, Matt Harbison <mharbison72 at gmail.com>  
wrote:

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

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

Yes, thanks for that explanation Matt, I'm beginning to see the subtleties  
now of properly managing the working directory.  I veered off the path  
conceptually by regarding the working directory vis-a-vis the repo as a  
sort of locale for total swap-outs between changesets, obviously  
disregarding the possibility of merges, which I need to do now to get back  
to par.

So rather than look at the working directory in such an absolute sense, I  
should be content to persist tracked files in the working directory, and  
merge/revert/update as-necessary with the occasional '--clean .'


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

Yes, and I've been adding to my schizophrenia by jumping between  
TortoiseHg, right-click menus and the command line!

Cheers,
John



More information about the Mercurial mailing list