flags: account for flag change when tracking rename relevant to merge There are some logic filtering rename to the one relevant to the merge. That logic was oblivious of flag change, leading to exec flag being dropped when merged with a renamed. There are two others bugs affecting this scenario. This patch fix the was where there is not modification involved except for the flag change. Fixes for the other bug are coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D8531

flags: also test merging a rename with and exec flag change This case is currently buggy and was not tested. This is probably a quite old regression. The next changeset fix this case. Move exec+rename related bug will gain a test later. To highlight the expected behavior the currently missing line are marked with (false !) and the bad one with (true !) note: we should probably gain explicit "test bool" for this usecases. Differential Revision: https://phab.mercurial-scm.org/D8530

flags: introduce explicit testing for merging change to exec flag It turns out that we do not seems to test the simple case for merging exec flag changes. More advanced case are test (merging exec flag without a common ancestors, merging with a symlink, etc…) but not the basic. We are about introduce various fixes to merging flag change across renames, having the most basic case tested first seems useful. note: We are only testing "adding" an exec flag here, not removing it. We introduce basic test on stable and will consolidate them on default. Differential Revision: https://phab.mercurial-scm.org/D8529

graft-state: save --base in graft's state, fixing bug with graft --continue Without this change, running graft --continue after grafting a merge commit using --base (and encountering conflicts) will output "skipping ungraftable merge revision" even though we specified a base in the initial graft command. Graft's improve behaviour is reflected in test-graft.t. Differential Revision: https://phab.mercurial-scm.org/D8578

setup: raise minimum Python version to 2.7.4 On older Python versions, Mercurial is not really usable because of https://bugs.python.org/issue10211. Recently someone reported a crash on the mailing list when running Mercurial on Python 2.7.3. There was consensus that fixing compatibility for a Python version more than 7 years old is not worth it. So, instead of making Mercurial crash with an obscure exception, this patch raises the minimum Python version to 2.7.4.

fsmonitor: coerce `clock` variable to byte-string (issue6321) Callers of `fsmonitor.state.setlastclock` pass their arguments wrapped in `pycompat.sysbytes` to ensure the value is a `bytes` on Python 3. However in `fsmonitor.poststatus.__call__`, if the return value of `getlastclock()` is `None`, we use the value of `fsmonitor.poststatus._startclock` instead, which is not converted to a byte string in the same manner. This commit converts the value of `startclock` to a byte string using `pycompat.sysbytes` in the constructor for `poststatus`, to avoid the "`str` + `bytes`" error from issue 6321. Differential Revision: https://phab.mercurial-scm.org/D8573

py3: change default priority and length used for sorting hooks to be compatible with python 3 The call to `sorted(hooks.values())` can on line 213 of hooks.py can raise when using python 3. For instance, when hooks.values is `[(0, 2, b'post-commit.check-status', b''), (None, None, b'changegroup.app-hooks', <object object at 0x7f5279885590>)]`, the error is `TypeError: '<' not supported between instances of 'NoneType' and 'int'` This fix keeps the same order that was used in python 2 without relying on comparison with None. Differential Revision: https://phab.mercurial-scm.org/D8527

relnotes: copy "next" to "5.4" and clear "next" This is the same thing as we've done for the previous few releases. Differential Revision: https://phab.mercurial-scm.org/D8546

dirstate: make sure the dirstate is loaded before the changelog (issue6303) Before this change, it was possible for the changelog to be loaded before the dirstate. If a transaction happens betwen the changelog and dirstate reading, the dirstate can up end poitning toward a revision not existing in the (olded) changelog. This lead to a warning. With this revision, we preload the dirstate parent before reading the changelog. This has a negligible performance impact on performance for all case we are tracking. Differential Revision: https://phab.mercurial-scm.org/D8528

rust-dirstatemap: don't read the dirstate when requesting parents A future patch for issue 6303 reveals a big performance regression in the Rust `DirstateMap` that reads the entire dirstate when requesting parents instead of the first 40 bytes. `perfdiscovery` gets a *significant* speedup (from 0.101 to 0.016) when applied against said patch. I'm assuming it has other performance benefits, but this is already a good enough win. Differential Revision: https://phab.mercurial-scm.org/D8513

py3: fix exception in pull when several things happen to a bookmark Specifically, when `changes` is: [(b'@upstream-committed', None, <function ui.status>, b'updating bookmark @upstream-committed\n'), (b'@upstream-committed', binary-node, <function ui.warn>, b'divergent bookmark @ stored as @upstream-committed\n')] sorting the list raises: TypeError: '<' not supported between instances of 'bytes' and 'NoneType' Differential Revision: https://phab.mercurial-scm.org/D8523

fastexport: adjust output to be more canonical For time zones, git doesn't consider +0 and -0 the same timezone, so use the former canonically. Add a test case to ensure that non-UTC offsets are handled correctly. The real name part of the committer name is normally not quoted, so don't enforce that. Differential Revision: https://phab.mercurial-scm.org/D8522