sslutil: check for missing certificate and key files (issue5598) Currently, sslutil._hostsettings() performs validation that web.cacerts exists. However, client certificates are passed in to the function and not all callers may validate them. This includes httpconnection.readauthforuri(), which loads the [auth] section. If a missing file is specified, the ssl module will raise a generic IOException. And, it doesn't even give us the courtesy of telling us which file is missing! Mercurial then prints a generic "abort: No such file or directory" (or similar) error, leaving users to scratch their head as to what file is missing. This commit introduces explicit validation of all paths passed as arguments to wrapsocket() and wrapserversocket(). Any missing file is alerted about explicitly. We should probably catch missing files earlier - as part of loading the [auth] section. However, I think the sslutil functions should check for file presence regardless of what callers do because that's the only way to be sure that missing files are always detected.

match: override matchfn instead of __call__ for consistency The matchers that were recently moved into core from the sparse extension override __call__, while the previously existing matchers override matchfn. Let's switch to the latter for consistency.

match: express anypats(), not prefix(), in terms of the others When I added prefix() in 9789b4a7c595 (match: introduce boolean prefix() method, 2014-10-28), we already had always(), isexact(), and anypats(), so it made sense to write it in terms of them (a prefix matcher is one that isn't any of the other types). It's only now that I realize that it's much more natural to define prefix() explicitly (it's one that uses path: patterns, roughly speaking) and let anypats() be defined in terms of the others. Remember that these methods are all used for determining which fast paths are possible. anypats() simply means that no fast paths are possible (it could be called complex() instead). Further evidence is that rootfilesin:some/dir does not have any patterns, but it's still considered to be an anypats() matcher. That's because anypats() really just means that it's not a prefix() matcher (and not always() and not isexact()). This patch thus changes prefix() to return False by default and anypats() to return True only if the other three are False. Having anypats() be True by default also seems like a good thing, because it means forgetting to override it will lead only to performance bugs, not correctness bugs. Since the base class's implementation changes, we're also forced to update the subclasses. That change exposed and fixed a bug in the differencematcher: for example when both its two input matchers were prefix matchers, we would say that the result was also a prefix matcher, which is incorrect, because e.g "path:dir - path:dir/foo" no longer matches everything under "dir" (which is what prefix() means).

match: make nevermatcher an exact matcher and a prefix matcher The m.isexact() and m.prefix() methods are used by callers to determine whether m.files() can be used for fast paths. It seems safe to let callers to any fast paths it can that rely on the empty m.files().

revset: define successors revset This revset returns all successors, including transit nodes and the source nodes (to be consistent with existing revsets like "ancestors"). To filter out transit nodes, use `successors(X)-obsolete()`. To filter out divergent case, use `successors(X)-divergent()-obsolete()`. The revset could be useful to define rebase destination, like: `max(successors(BASE)-divergent()-obsolete())`. The `max` is to deal with splits. There are other implementations where `successors` returns just one level of successors, and `allsuccessors` returns everything. I think `successors` returning all successors by default is more user friendly. We have seen cases in production where people use 1-level `successors` while they really want `allsuccessors`. So it seems better to just have one single revset returning all successors by default to avoid user errors. In the future we might want to add `depth` keyword argument to it and for other revsets like `ancestors` etc. Or even build some flexible indexing syntax [1] to satisfy people having the depth limit requirement. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-July/101140.html

sparse: shorten try..except block in updateconfig() It now only covers refreshwdir(). This is what importfromfiles() does. I think it is the more appropriate behavior.

sparse: clean up updateconfig() * Use context manager for wlock * Rename oldsparsematch to oldmatcher * Always call parseconfig() because parsing an empty string yields the same result as the old code

sparse: move config updating function into core As part of the move, the ui argument was dropped. Additional fixups will be made in a follow-up commit.

dirstate: expose a sparse matcher on dirstate (API) The sparse extension performs a lot of monkeypatching of dirstate to make it sparse aware. Essentially, various operations need to take the active sparse config into account. They do this by obtaining a matcher representing the sparse config and filtering paths through it. The monkeypatching is done by stuffing a reference to a repo on dirstate and calling sparse.matcher() (which takes a repo instance) during each function call. The reason this function takes a repo instance is because resolving the sparse config may require resolving file contents from filelogs, and that requires a repo. (If the current sparse config references "profile" files, the contents of those files from the dirstate's parent revisions is resolved.) I seem to recall people having strong opinions that the dirstate object not have a reference to a repo. So copying what the sparse extension does probably won't fly in core. Plus, the dirstate modifications shouldn't require a full repo: they only need a matcher. So there's no good reason to stuff a reference to the repo in dirstate. This commit exposes a sparse matcher to dirstate via a property that when looked up will call a function that eventually calls sparse.matcher(). The repo instance is bound in a closure, so it isn't exposed to dirstate. This approach is functionally similar to what the sparse extension does today, except it hides the repo instance from dirstate. The approach is not optimal because we have to call a proxy function and sparse.matcher() on every property lookup. There is room to cache the matcher instance in dirstate. After all, the matcher only changes if the dirstate's parents change or if the sparse config changes. It feels like we should be able to detect both events and update the matcher when this occurs. But for now we preserve the existing semantics so we can move the dirstate sparseness bits into core. Once in core, refactoring becomes a bit easier since it will be clearer how all these components interact. The sparse extension has been updated to use the new property. Because all references to the repo on dirstate have been removed, the code for setting it has been removed.

sparse: use self instead of repo.dirstate "self" here is the dirstate instance. I'm pretty confident that self and repo.dirstate will be the exact same object. So remove a dependency on repo by just looking at self.

sparse: move code for importing rules from files into core This is a pretty straightforward port. Some code cleanup was performed. But no major changes to the logic were made. I'm not a huge fan of this function because it does multiple things. I'd like to get things into core first to facilitate refactoring later. Please also note the added inline comment about the oddities of writeconfig() and the try..except to undo it. This is because of the hackiness in which the sparse matcher is obtained by various consumers, notably dirstate. We'll need a massive refactor to address this. That refactor is effectively blocked on having the sparse dirstate hacks live in core.

sparse: refactor activeprofiles into a generic function (API) activeprofiles() is a special case of a more generic function. Furthermore, that generic function is essentially already implemented inline in the sparse extension. So, refactor activeprofiles() to a generic activeconfig(). Change the only consumer of activeprofiles() to use it. And have the inline implementation in the sparse extension use it.

check-code: prohibit `if False` antipattern Differential Revision: https://phab.mercurial-scm.org/D20

convert: remove `if False` block This code has never run since its introduction on July 18th, 2007. It's time for it to go. Differential Revision: https://phab.mercurial-scm.org/D19

filterpyflakes: move self-test into test file This will avoid a false positive on an upcoming check-code rule. Differential Revision: https://phab.mercurial-scm.org/D18

test-subrepo: demonstrate a status problem when merge deletes a file At the interactive update prompt, if (c) is chosen and then followed by `hg rm`, both `status -R` and `status -S` show the file as 'R', and `files -R` shows no files (OK, because explicitly removed files aren't supposed to be listed). If `rm` follows selecting (c), then both flavors of `status` list the file as '!', and `files -R` lists the missing file. So somehow, the (d) option has followed a third path.

subrepo: make the output references to subrepositories consistent Well, mostly. The annotation on subrepo functions tacks on a parenthetical to the abort message, which seems reasonable for a generic mechanism. But now all messages consistently spell out 'subrepository', and double quote the name of the repo. I noticed the inconsistency in the change for the last commit.

subrepo: consider the parent repo dirty when a file is missing This simply passes the 'missing' argument down from the context of the parent repo, so the same rules apply. subrepo.bailifchanged() is hardcoded to care about missing files, because cmdutil.bailifchanged() is too. In the end, it looks like this addresses inconsistencies with 'archive', 'identify', blackbox logs, 'merge', and 'update --check'. I wasn't sure how to implement this in git, so that's left for someone more familiar with it.

archival: flag missing files as a dirty wdir() in the metadata file (BC) Since the identify command adds a '+' for missing files, it's reasonable that this does too. Perhaps the node field's hex value should be p1+p2 for merges?

cmdutil: simplify the dirty check in howtocontinue() This is equivalent to the previous code. But it seems to me that if the user is going to be prompted that a commit is needed, missing files should be ignored, but branch and merge changes shouldn't be.

blackbox: simplify the dirty check Same idea (and possibly incorrect behavior) as the previous commit.

identify: simplify the dirty check This is equivalent to the previous code, but it seems better to be explicit about what aspects of dirty are being ignored. Perhaps they shouldn't be, since the help text says 'followed by a "+" if the working directory has uncommitted changes'. Both merges and branch changes are committable, even if the files are unchanged. Additionally, this will make the `identify` command notice missing subrepo files, once subrepos are taught to look for missing files.

tests: tweak the subrepo dirty state tests This is a continuation of 439b4d005b4a. I overlooked that blackbox logs also have a dirty marker. Also, the `hg update --check` test was updating to a revision where the deleted file wasn't tracked, which is why status seemed to show the deleted file was restored.

match: combine regex code for path: and relpath: The regexes for path: and relpath: patterns are the same (since the paths have already been normalized at the point we create the regexes). I don't think the "if pat == '.'" will have any effect relpath: because relpath: patterns will have the root directory already normalized to '' by pathutil.canonpath() (unlike path:, for which the root gets normalized to '.' by util.normpath()).

match: remove unnecessary '^' from regexes The regexes are passed to re.match(), which matches against the beginning of the input, so the '^' doesn't do anything. Note that unrooted patterns, such as globs and regexes from .hgignore are instead achieved by adding '.*' to the expression given by the user. (That's unless the user's expression started with '^', in which case the '.*' is not added, perhaps to keep the regex cleaner?)

sparse: access status fields by name instead of deconstructing it The status tuples has had named fields for a few years now.

sparse: move printing of sparse config changes function into core As part of the port, all arguments now have default values of 0. Strings are now also given the i18n treatment.

sparse: move code for clearing rules to core This is a pretty straightforward port.

sparse: move post commit actions into core Instead of wrapping committablectx.markcommitted(), we inline the call into workingctx.markcommitted(). Per smf's review, workingctx is the proper location for this code, as committablectx is the shared base class for it and memctx. Since this code touches the working directory, it belongs in workingctx.

cleanupnode: do not use generator for node mapping The 'successors' part of the mappings used of be a tuple. This avoid issue from code consuming the generator "by mistake". For example, an extension inspecting the mapping content used to be able to iterate over the successors mapping without consequence. Since the mapping are small we do not expect any performance impact we use tuple again for this.

histedit: use scmutil.cleanupnodes (BC) This is marked as BC because the strip backup file name has changed.

histedit: unify strip backup files on success (BC) Previously we wrote two different strip backup files on success. This patch unifies them. It will make scmutil.cleanupnodes migration more smooth.

histedit: pass multiple nodes to strip (BC) Previously, histedit.cleanupnode pass root nodes one by one. Since repair.strip takes multiple nodes and can handle them just fine, pass all strip roots at once. This is BC because the number of strip backup files may change from N to 1.

histedit: remove "name" parameter from cleanupnode functions The "name" parameter is not used any longer so let's remove it.

histedit: remove "should strip" debug message The debug message was not used anywhere. Removed it to make scmutil.cleanupnodes migration easier to reason about.

histedit: move topmost bookmark movement to a separate function histedit treats topmost bookmark movement specially. The rest of the bookmark movement could be handled by scmutil.cleanupnodes. So let's move the special logic out to make the patch easier to review.

histedit: remove moving bookmarks message on verbose (BC) This is more consistent with other commands, like "commit -v" won't show bookmark movement messages. It will make migrating to scmutil.cleanupnodes easier.

test-largefiles-update: conditionalize output instead of tests

test-status-rev: conditionalize output instead of tests

test-mq: conditionalize output instead of tests

test-annotate: conditionalize output instead of tests

test-addremove: conditionalize output instead of tests

test-tools: conditionalize output instead of tests

test-rebase: conditionalize output instead of tests This should help prevent breakage like was fixed in the last patch.

tests: stabilize on Windows I'm not sure if the difference on Windows for test-sparse.t is expected or not. It looks like unless the leading '/' is followed by a drive letter, '/' is resolved to 'C:/MinGW/msys/1.0'. But both cases abort with "not under root" instead of just warning.

revset: make repo.anyrevs accept customized alias override (API) Previously repo.anyrevs only expand aliases in [revsetalias] config. This patch makes it more flexible to accept a customized dict defining aliases without having to couple with ui. revsetlang.expandaliases now has the signature (tree, aliases, warn=None) which is more consistent with templater.expandaliases. revsetlang.py is now free from "ui", which seems to be a good thing.

tests: quote $PYTHON for Windows When unquoted, MSYS sees the colon between the drive letter and path as a Unix path separator and unhelpfully splits on it, feeding only the drive letter as the command. Much chaos ensues. I vaguely remember trying to get the test runner to use /letter/path/to/exe syntax the last time this happened, without success. I doubt a check-code rule would work, since sometimes it is quoted, and sometimes the quotes are escaped.

amend: use scmutil.cleanupnodes (BC) This is marked as BC because the strip backup file name has changed.

rebase: remove "if True" The "if True" block was to make the last patch easier to review. This patch removes "if True" and unindents the block.

rebase: use scmutil.cleanupnodes (issue5606) (BC) This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies the code and makes rebase code reusable inside a transaction. This is a BC because the backup file is no longer strip-backup/*-backup.hg, but strip-backup/*-rebase.hg. The latter looks more reasonable since the directory name is "strip-backup" so there is no need to repeat "backup". I think the backup file name change is probably fine as a BC, since we have changed it before (aa4a1672583e) and didn't get complains. The end result of this series will be a much more consistent and unified backup names: command | old backup file suffix | new backup file suffix ------------------------------------------------------------------- amend | amend-backup.hg | amend.hg histedit | backup.hg (could be 2 files) | histedit.hg (single file) rebase | backup.hg | rebase.hg strip | backup.hg | backup.hg (note: backup files are under .hg/strip-backup) It also fixes issue5606 as a side effect because the new "delayedstrip" code path will carefully examine nodes (safestriproots) to make sure orphaned changesets won't get stripped by accident. Some warning messages are changed to the new "warning: orphaned descendants detected, not stripping HASHES", which provides more information about exactly what changesets are left behind. Another minor behavior change is when there is an obsoleted changeset with a successor in the destination branch, bookmarks pointing to that obsoleted changeset will not be moved. I have commented in test-rebase-obsolete.t explaining why that is more desirable.

scmutil: make cleanupnodes delete divergent bookmarks cleanupnodes takes care of bookmark movement, and bookmark movement could cause bookmark divergent resolution as a side effect. This patch adds such bookmark divergent resolution logic so future rebase migration will be easier. The revset is carefully written to be equivalent to what rebase does today. Although I think it might make sense to remove divergent bookmarks more aggressively, for example: F book@1 | E book@2 | | D book | | | C |/ B book@3 | A When rebase -s C -d E, "book@1" will be removed, "book@3" will be kept, and the end result is: D book | C | F | E book@2 (?) | B book@3 | A The question is should we keep book@2? The current logic keeps it. If we choose not to (makes some sense to me), the "deleterevs" revset could be simplified to "newnode % oldnode". For now, I just make it compatible with the existing behavior. If we want to make the "deleterevs" revset simpler, we can always do it in the future.

scmutil: make cleanupnodes handle filtered node In some valid usecases, the "mapping" received by scmutil.cleanupnodes have filtered nodes. Use unfiltered repo to access them correctly. The added test case will fail with the old cleanupnodes code. This is important to migrate histedit to use the cleanupnodes API.

configitems: add alias support in config Aliases define optional alternatives to existing options. For example the old option ui.user was deprecated and replaced by ui.username. With this mechanism, it's even possible to create an alias to an option in a different section. Add ui.user as alias to ui.username as an example of this concept. The old alternates principle in ui.config is removed as it was used only for this option.

hgweb: use ui._unset to prevent a warning in configitems

dispatch: fix typo suggestion for disabled extension If the matching command lives in an in-tree extension (which is all we scan for), and the user has disabled that extension with "extensions.<name>=!", we were not finding it, because the path in _disabledextensions was the empty string. If the user had set "extensions.<name>=!<valid path>" it would work, so it seems like just a mistake that it didn't work.

tests: add tests for typoed commands This includes one test showing how disabling a command with e.g. "extensions.rebase=!" results in the command not being suggested. We'll fix that next.

sparse: inline signature cache clearing It is a trivial one-liner. No need to have a separate function.

sparse: move working directory refreshing into core This is a pretty straightforward move of the code. I converted the "force" argument to a keyword argument. Like other recent changes, this code is tightly coupled with working directory update code in merge.py. I suspect the code will become more tightly coupled over time, possibly even moved to merge.py. For now, let's get the code in core.

sparse: refactor update actions filtering and call from core merge.calculateupdates() now filters the update actions through sparse by default. The filtering no-ops if sparse isn't enabled or no sparse config is defined. The function has been refactored to behave more like a filter instead of a wrapper of merge.calculateupdates(). We should arguably take sparse into account earlier in merge.calculateupdates(). This patch preserves the old behavior of applying sparse at the end of update calculation, which is the simplest and safest approach.

sparse: move update action filtering into core This is a relatively straight port of the function. It is pretty large. So refactoring will be postponed to a subsequent commit.