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