histedit: add missing b prefix to a string If i18n is disabled (such as via HGPLAIN=1), `_()` doesn't convert from str to bytes, so this raises a TypeError on py3. Differential Revision: https://phab.mercurial-scm.org/D8354

py3: require values in changelog extras to be bytes I don't know what happened here because b436059c1cca (py3: use pycompat.bytestr() on extra values because it can be int, 2019-02-05) came about b44a47214122 (py3: use string for "close" value in commit extras, 2018-02-11). Whatever happened, we shouldn't need to convert the values to bytes now. It's better to not convert because that might cover up bugs where someone sets a unicode value in the extras and that works until the unicode value happens to contain non-ascii (at which point it will fail because `bytestr()` expects its argument to be ascii if it's unicode). Differential Revision: https://phab.mercurial-scm.org/D8332

py3: make setup.py's hgcommand() consistently return bytes Before this patch, it returned unicode when the command failed. That made e.g. `make local PYTHON=python3` fail on an obsolete commit. Differential Revision: https://phab.mercurial-scm.org/D8331

darwin: use vim, not vi, to avoid data-loss inducing posix behavior Apple's version of vim, available at opensource.apple.com/release/macos-1015.html (for Catalina, but this behavior has been there for a while) has several tweaks from the version of vim from vim.org. Most of these tweaks appear to be for "Unix2003" compatibility. One of the tweaks is that if any ex command raises an error, the entire process will (when you exit, possibly minutes/hours later) also exit non-zero. Ex commands are things like `:foo`. Luckily, they only enabled this if vim was executed (via a symlink or copying the binary) as `vi` or `ex`. If you start it as `vim`, it doesn't have this behavior, so let's do that. To see this in action, run the following two commands on macOS: ``` $ vi -c ':unknown' -c ':qa' ; echo $? 1 $ vim -c ':unknown' -c ':qa' ; echo $? 0 ``` We don't want to start ignoring non-zero return types from the editor because that will mean you can't use `:cquit` to intentionally exit 1 (which, shows up as 2 if you combine an ex command error and a cquit, but only a 1 if you just use cquit, so we can't differentiate between the two statuses). Since we can't differentiate, we have to assume that all non-zero exit codes are intentional and an indication of the user's desire to not continue with whatever we're doing. If this was a complicated `hg split` or `hg histedit`, this is especially disastrous :( Differential Revision: https://phab.mercurial-scm.org/D8321