Typo in .hgsub renders revisions un-checkout-able

Greg Ward greg at gerg.ca
Thu Nov 22 09:22:05 CST 2012


On 21 November 2012, Matt Mackall said:
> 
> (not at all specific to git)

I suspected as much.

> We don't have a way to mark a working directory as "broken, don't even
> think about checking this in", which makes this a hard-to-get-to
> solution space.

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?

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

In both cases, we need to print a message telling the user what
happened ("did an update abort? or get interrupted?") and what they
can do about it ("make sure you have no valuable uncommitted changes,
then run hg update --clean"). A wiki page explaining the situation
might be in order too.

So far, this improves several scenarios:

  * user hits ctrl-c during update
  * user trips over power cord during update
    (same, but we have to handle it after the fact)
  * abort during update for whatever reason
  * other crash during update (unhandled exception)

But this does nothing about aborts due to bad .hgsub. Continue:

3) modify subclasses of abstractsubrepo to raise something other than
   util.Abort() when we discover a bad subrepo URL (which probably
   only happens when hg clone/git clone/svn update fails -- I don't
   think subrepo.py should try to comprehend git/svn URLs)
4) catch that exception a little higher up the stack, print a nice
   warning message, and arrange that update fails in a more controlled
   way -- finish the update process, but do *not* clear the
   "unfinished update" bit

The last piece of the puzzle: how do we let the user commit after they
fix the typo in .hgsub?

  * force them to manually clear the "unfinished update" bit (blechh:
    I'm trying to fix a problem that requires awkward manual
    workarounds, so introducing new ones is no help)
  * add a flag to commit that basically boils down to the above
  * distinguish update failure modes so we can tell "update aborted"
    from "update failed due to bad .hgsub", and let commit proceed
    as long as only .hgsub is modified

I'm not thrilled with any of those. Better ideas?

       Greg


More information about the Mercurial-devel mailing list