Typo in .hgsub renders revisions un-checkout-able

Greg Ward greg at gerg.ca
Sun Nov 25 22:36:07 CST 2012


On Sun, Nov 25, 2012 at 5:24 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2012-11-22 at 10:22 -0500, Greg Ward wrote:
>> Ahh, which gets to the old "don't hit ctrl-c during hg update"
>> problem. Or "don't do anything that might make hg stumble across a
>> util.Abort() call during hg update". Which is really what this subrepo
>> problem boils down to.
>>
>> So: I presume you would not take a patch that fixes subrepo.py to
>> print a scary "inconsistent working dir" warning unless we also have a
>> way to prevent subsequently committing?
>
> Probably not.
>
>> Possible plan:
>>
>> 1) modify "hg update" so that before starting, it writes a bit of
>>    state (zero-byte file?) recording that the working dir is
>>    inconsistent, and clear that bit when update is complete
>> 2) modify localrepo.commit() to abort if that file is present
>
> You also need:
>
> 3) show this state in 'hg summary'

And, IMHO, "hg status" and "hg diff". "Why the heck are 7000 files
suddenly modified? I didn't touch them!!!" My rough preliminary patch
handles this in localrepo.status().

> 4) add various ways to leave this state
>   a) hg up (--clean required?)
>   b) hg commit --force

I've toyed around with figuring a manual recovery procedure -- an
obvious prerequisite to automating it. If there were no local changes
before the interrupted update, it's easy: "hg update --clean .". But
if you have valuable uncommitted changes mixed in with the gunk from
an interrupted update, it's messy. I think it's necessary to remember
what the modified/added/removed files were before the update in order
to have a hope in hell of recovering.

One idea occurred to me: broaden the mandate of "hg recover" from

    Recover from an interrupted commit or pull.

to

    Recover from an interrupted operation.

After all, recover is already smart enough to know when it has no
aborted transaction to deal with, so presumably that logic can be
extended to know about an interrupted update.

--
Greg Ward                            http://www.gerg.ca
<greg at gerg.ca>                       @gergdotca


More information about the Mercurial-devel mailing list