help: update help text for debug-repair-
issue6528
The changegroup fix was put in 5.9.1, this is now out of date. Alson, this can
maybe encourage people to upgrade?
Differential Revision: https://phab.mercurial-scm.org/D11392
dispatch: use detailed exit code 250 for keyboard interrupt
Among our users at Google, we're still seeing several percent of
commands fail with exit code 255. I suspect keyboard interrupts is an
important remaining reason.
This is a resend of D10086 with some fixes for pager handling added
ahead of it.
Differential Revision: https://phab.mercurial-scm.org/D11628
dispatch: ignore failure to flush ui
When the pager dies, we get a `SIGPIPE`. That causes
`error.SignalInterrupt` to be raised ` (from `ui._catchterm()`). Any
further writes or flushes will cause further `SIGPIPE`s and furhter
`error.SignalInterrupt`. If we write or flush outside of the
try/except that handle `KeyboardInterrupt` (which
`error.SignalInterrupt` is a subclass of), then control will escape
from the `dispatch` module. Let's fix that by ignoring errors from
flushing the ui.
I would have rather fixed this by restoring the stdout and stderr
streams when the pager dies, but it gets complicated because of
multiple ui instances (ui/lui) and different pager setups between
regular hg and chg.
This changes a test in `test-pager.t`, but I don't understand why. I
would have thought that all the output from the command should have
gone to the broken pager.
Differential Revision: https://phab.mercurial-scm.org/D11627
dispatch: don't change error status if flushing stdio fails
If we already have a non-zero exit code, I don't think we should
change it to 255 because we fail to flush stdio. This may not matter
yet, but it will matter when I make a killed pager result in exit code
250 (it's currently 255).
Differential Revision: https://phab.mercurial-scm.org/D11626