terse: pconvert() entries added to the temporary terse dict for Windows Recent additional testing revealed this problem on Windows: --- tests/test-status.t.err +++ tests/test-status.t.err @@ -109,7 +109,7 @@ tweaking defaults works $ hg status --cwd a --config ui.tweakdefaults=yes - ? . + ? ../a/ ? ../b/ ? ../in_root $ HGPLAIN=1 hg status --cwd a --config ui.tweakdefaults=yes @@ -120,7 +120,7 @@ ? b/in_b (glob) ? in_root $ HGPLAINEXCEPT=tweakdefaults hg status --cwd a --config ui.tweakdefaults=yes - ? . + ? ..\a\ ? ../b/ ? ../in_root (glob) AFAICT, the status list (input and output here) is always in '/' format. The '\' printed output on Windows is because each file is run through repo.pathto() -> dirstate.pathto() -> util.pathto(). (And that function states that the argument uses '/' separators.) I fixed a similar issue in 362096cfdb1f, and given the apparent need for these strings to be in '/' format, I wonder if cmdutil.dirnode() should be rewritten to avoid os.path.join(). But it looks like all entries added to the temporary terse dict should use '/' now, and cmdutil.tersedir() looks like the only user.

filemerge: don't pass function name as loadpath's module_name param

phases: define an official tuple of phases we do not share Same motivation as for `mutablephases`, having a single definition helps with updating phases logic.

phases: define an official tuple of mutable phases Such tuple was already manually defined in a couple of place. Having an official definition makes it easy to introduce of new phases.

repoview: use 'phasecache.getrevset' when computing 'unserved' filter This reuses a precomputed set, being much faster than manual iteration. Computing the "unserved" filter speed up by 55%. before: wall 0.014671 comb 0.020000 user 0.020000 sys 0.000000 (best of 180) after: wall 0.006623 comb 0.010000 user 0.010000 sys 0.000000 (best of 401) The "unserved" filter is used to restrict the revisions client can pull from a server. (eg: secret changesets)

graft: drop --user and --date values info from hint in case of conflicts After previous patch, we have started preserving user and date values in graftstate and reusing them during `hg graft --continue`. Now passing --user and --date again with --continue makes no sense. Let's drop them from the hint. Differential Revision: https://phab.mercurial-scm.org/D3660

graft: reuse --user and --date values in `hg graft --continue` (BC) Reading the user and date information from graftstate during `hg graft --continue` will help us in preserving the user and date arguments passed when `hg graft` was called. This patch reads that information and reuses that while running `hg graft --continue`. So after this patch, --user and --date values are preserved even if conflicts occur and user don't need to pass them again. The test changes demonstrate the fix. This is a backward incompatible change but I think of this more as a bug fix. Also thinking about removing the line from `hg help graft` which says --continue does not reapply other flags but need to check what are the other flags which needs to be preserved. Differential Revision: https://phab.mercurial-scm.org/D3659

tests: add test showing --continue not preserving --date and --user flags This patch adds test showing that we don't preserve the user passed --date and --user values in `hg graft`. I was fixing that and realized this is untested. Adding tests before so that behavior change or the fix is easy to realize. Differential Revision: https://phab.mercurial-scm.org/D3658

graft: store user passed date and user information in graftstate Right now, `hg help graft` says: The -c/--continue option does not reapply earlier options, except for --force. which should be treated as a bug. A good user experience is that the commands remember the arguments passed initially and preserve them during `hg graft --continue`. This patch starts storing the user and date information in graftstate if user passed it. Upcoming patches will make sure we preserve that information during --continue and them don't allow user to pass any new arguments with --continue. I don't think there is any another `--continue` flag which allows new options to be passed with it. Differential Revision: https://phab.mercurial-scm.org/D3657

graft: use cmdstate.delete() to delete the state file Previous patches start using state.cmdstate() class for statefiles. The class has a function delete() to delete the state file. This patch replaces the existing repo.vfs.unlink() with that delete() function. Differential Revision: https://phab.mercurial-scm.org/D3656