Typo in .hgsub renders revisions un-checkout-able

[Matt Mackall]

On Sun, 2012-11-25 at 23:36 -0500, Greg Ward wrote:
> 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().

And does what? Aborts? Realistically, people might want to use this data
in their recovery process.

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

You're a dreamer. There are enough small details (exec bits, symlinks)
and non-reversible operations (gets, removes, automated merges) in
update that this is hard to do with no time or disk space overhead.

Also, you have to be careful to avoid even appearing to promise that 'hg
update --clean + ctrl-c + hg fix' will get back anything --clean might
have clobbered.

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

Hmmm, might suggest it covers merge, graft, rebase, transplant...

-- 
Mathematics is the supreme nostalgia of our time.