Correcting title.

>> It seems to be quite easy for a user to commit a change to a subrepo that
they then fail to push.

That doesn't match your description of how this happened and doesn't seem to
be true: Mercurial pushes subrepos before repos.

>> In this case, a developer updated the .hgsub file to point one subrepo at
a new URL, but he didn't know that he also needed to update the contained
subrepo to be a clone of that URL

Hadn't anticipated that. But it's not clear what should be done. Checking
out an incomplete state is a good way to later check in, build, or otherwise
silently perpetuate a highly broken state and Mercurial generally refuses to
do it whether subrepos are involved or not. We fail similarly for things
like case collisions and unwritable directories.

Also, it doesn't seem like we can detect this case on the commit side. The
committer may or may not have manually retargeted the subrepo properly and
we won't even know if the new target subrepo exists until we try to push. If
we have nothing to push in the subrepo, we won't even try that much.

We could prevent some errors by making a command to manipulate subrepos,
probably with subcommands like add and remove. But would we have a retarget
command? Or would we simply insist on doing remove (which removes the local
sub) followed by add (which repulls it)?