global: use python3 in shebangs Python 3 is the future. We want Python scripts to be using Python 3 by default. This change updates all `#!/usr/bin/env python` shebangs to use `python3`. Does this mean all scripts use or require Python 3: no. In the test environment, the `PATH` environment variable in tests is updated to guarantee that the Python executable used to run run-tests.py is used. Since test scripts all now use `#!/usr/bin/env python3`, we had to update this code to install a `python3` symlink instead of `python`. It is possible there are some random scripts now executed with the incorrect Python interpreter in some contexts. However, I would argue that this was a pre-existing bug: we should almost always be executing new Python processes using the `sys.executable` from the originating Python script, as `python` or `python3` won't guarantee we'll use the same interpreter. Differential Revision: https://phab.mercurial-scm.org/D9273

tests: use python from environment in test-parseindex2.py Without this, the test starts failing with D9273 (the change to `pyexename` to be specific). Differential Revision: https://phab.mercurial-scm.org/D9286

errors: set detailed exit code to 20 for locking errors This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9242

errors: introduce InputError and use it from commands and cmdutil This patch introduces a `InputError` class and replaces many uses of `error.Abort` by it in `commands` and `cmdutil`. This is a part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. There will later be a different class for state errors (to raise e.g. when there's an unfinished operation). It's not always clear when one should report an input error and when it should be a state error. We can always adjust later if I got something wrong in this patch (but feel free to point out any you notice now). Differential Revision: https://phab.mercurial-scm.org/D9167

errors: add config that lets user get more detailed exit codes This adds an experimental config that lets the user get more detailed exit codes. For example, there will be a specific error code for input/user errors. This is part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. I've made the config part of tweakdefaults. I've made the config enabled by default in tests. My reasoning is that we want to see that each specific error case gives the right exit code and we don't want to duplicate all error cases in the entire test suite. It also makes it easy to grep the `.t` files for `[255]` to find which cases we have left to fix. The logic for the current exit codes is quite simple, so I'm not too worried about regressions there. I've added a test case specifically for the "legacy" exit codes. I've set the detailed exit status only for the case of `InterventionRequired` and `SystemExit` for now (the cases where we currently return something other than 255), just to show that it works. Differential Revision: https://phab.mercurial-scm.org/D9238

worker: raise exception instead of calling sys.exit() with child's code When a worker process returns an error code, we would call `sys.exit()` with that exit code on the main process. The `SystemExit` exception would then get caught in `scmutil.callcatch()`, which would return that error code. The comment there says "Commands shouldn't sys.exit directly", which I agree with. This patch changes it so we raise a specific exception when a worker fails so we can catch instead. I think that means that `SystemExit` is now always an internal error. (I had earlier thought that this call to `sys.exit()` was from within the child process until Matt Harbison made me look again, so thanks for that!) Differential Revision: https://phab.mercurial-scm.org/D9287

config: read system hgrc in lexicographical order This is similar to edbcf5b239f9 (config: read configs from directories in lexicographical order, 2019-04-03). Apparently I forgot to sort the system hgrc files there. That's fixed by this patch. Differential Revision: https://phab.mercurial-scm.org/D9269

relnotes: drop 5.6 release entries from next Differential Revision: https://phab.mercurial-scm.org/D9282

merge with stable

makefile: use Python 3 by default (BC) This change is long overdue IMO. .. bc:: Makefile now uses `python3` instead of `python` by default on non-Windows platforms. This means Mercurial will be built and run with Python 3 instead of Python 2.7 by default. To continue using Python 2, set the PYTHON variable. e.g. `make install PYTHON=python2.7`. Differential Revision: https://phab.mercurial-scm.org/D7258

hgweb: don't call sys.exit() in httpservice.run() If I'm reading the code correctly, `mercurial.server.createservice()` can return an hgweb service or one of three types of command server services. The caller then calls `mercurial.server.runservice()`, passing it the returned service's run method. Only the hgweb service was calling `sys.exit()`. It has been that way since 8d44649df03b (refactor ssh server., 2006-06-04). That commit message doesn't provide any explanation. Let's clean up and have the code follow the usual return path into the `dispatch` module. After this patch, there should be no remaining places left where we call `sys.exit()` except for valid uses in the `dispatch` and `worker` modules. Differential Revision: https://phab.mercurial-scm.org/D9272

serve: simply return instead of calling sys.exit() in `hg serve --stdio` The shouldn't be a reason to call `sys.exit()` instead of letting the code return normally. I've remove the call in both `hg serve` and `hg debugserve`. Differential Revision: https://phab.mercurial-scm.org/D9271

httpservice: move sys.exit() out of serve_forever() This is a simple refactoring to show the callers of the method, so it's easier to reason about the impact of removing the `sys.exit()` calls in subsequent patches. Differential Revision: https://phab.mercurial-scm.org/D9270

copies: handle more cases where a file got replaced by a copy This patch fixes the changeset-centric version in a pretty straight-forward way. It fixes it to automatically resolve the conflict, which is better than resulting in a modify/delete conflict as it was before b4057d001760 (merge: when rename was made on both sides, use ancestor as merge base, 2020-01-22). I'll leave it for later to test and explicitly handle cases where files have been renamed to the same target on different sides of the merge. Differential Revision: https://phab.mercurial-scm.org/D8653