Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Mar 2021 09:33:25 -0800] rev 48198
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 Oct 2021 13:36:02 -0700] rev 48197
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 08 Oct 2021 13:34:33 -0700] rev 48196
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
Simon Sapin <simon.sapin@octobus.net> [Mon, 11 Oct 2021 17:31:27 +0200] rev 48195
dirstate-v2: Use "byte sequence" in docs
The patch originally sent as https://phab.mercurial-scm.org/D11546
used "byte string" but that was changed during review to avoid suggesting
Unicode or character encodings.
However "byte range" sounds to be like a range of *indices* within a byte
string/sequence elsewhere.
This changes to "byte sequence". Python docs use "sequence" a lot when
discussing the `bytes` type: https://docs.python.org/3/library/stdtypes.html
Differential Revision: https://phab.mercurial-scm.org/D11623