changegroup: use any node, not min(), in treemanifest's generatemanifests This is fixing quadratic behavior, which is probably not noticeable in the common case, but if a very large directory gets added here, it can get pretty bad. This was noticed because we had some pushes that spent >25s in changegroup generation calling min() here, according to profiling. The original reasoning for min() being used in 829d369fc5a8 was that, at that point in the series, we were adding almost everything to tmfnodes during the first iteration through the loop , so we needed to avoid sending child directories before parents. Later changes made it so that the child directories were added only when we visited the parent directory (not all of them on the first iteration), so this is no longer necessary - there won't be any child directories in tmfnodes before the parents have been sent. This does mean that the manifests are now exchanged unordered, whereas previously we would essentially do [a, b, b/c, b/c/d, e], we now can send a, b, and e in any order; b/c must still follow b, and b/c/d must still follow b/c. Differential Revision: https://phab.mercurial-scm.org/D1351

bundle: allow bundlerepo to support alternative manifest implementations With our treemanifest logic, the manifests are no longer transported as part of the changegroup and are no longer stored in a revlog. This means the self.manifestlog line in bundlerepo.filestart no longer calls _constructmanifest, and therefore does not consume the manifest portion of the changegroup, which means filestart is not populated and we result in an infinite loop. The fix is to make filestart aware that self.manifestlog might not consume the changegroup part, and consume it manually if necessary. There's currently no way to test this in core, but our treemanifest extension has tests to cover this. Differential Revision: https://phab.mercurial-scm.org/D1329

obsfate: makes successorsetverb takes the markers as argument Right now, successorsetverb only needs successors to compute the verb. But we will want use additional information (effect-flags and operation) in the near future to compute a better verb. Add the markers parameter now so extensions (like Evolve) could wrap the function and start experimenting around better obsfate verbs. As successorsetverb now takes both successorset and markers parameters, rename it to obsfateverb, successorsetandmarkersverb was too long. Differential Revision: https://phab.mercurial-scm.org/D1191

scmutil: don't try to delete origbackup symlinks to directories (issue5731) When origbackuppath is set, when looking to see if a file we are backing up conflicts with a directory in the origbackuppath, we incorrectly match on symlinks to directories. This means we try to call vfs.rmtree on the symlink, which fails. Differential Revision: https://phab.mercurial-scm.org/D1311

tests: add a test demonstrating issue5731 If origbackups are in use, a symlink to a valid directory is backed up, and an update is made that attempts to backup a file or link over that symlink, we abort with a bad error message instead of successfully updating. Differential Revision: https://phab.mercurial-scm.org/D1310

cmdutil: create dirs for templated cat file output Previously, the caller was responsible for creating the directory structure of files written out using a path template. This is onerous, especially if the exact filenames are not known upfront, but are being accessed via a matcher. This patch changes things so that hg will attempt to create the appropriate directories before writing the output file. Differential Revision: https://phab.mercurial-scm.org/D1332

cat: test output path behvaior when target path does not exist In the next patch, we will change the behavior of the cat command to create output file parent directories before attempting to write the output file. This patch documents the current unfortunate behavior. Differential Revision: https://phab.mercurial-scm.org/D1331

py3: handle keyword arguments in hgext/shelve.py Differential Revision: https://phab.mercurial-scm.org/D1324

py3: handle keyword arguments in hgext/uncommit.py Differential Revision: https://phab.mercurial-scm.org/D1323

py3: handle keyword arguments in hgext/releasenotes.py Differential Revision: https://phab.mercurial-scm.org/D1322

py3: handle keyword arguments in hgext/rebase.py Differential Revision: https://phab.mercurial-scm.org/D1321

py3: handle keyword arguments in hgext/keyword.py Differential Revision: https://phab.mercurial-scm.org/D1320

py3: handle keyword arguments in hgext/journal.py Differential Revision: https://phab.mercurial-scm.org/D1319

py3: handle keyword arguments in hgext/histedit.py Differential Revision: https://phab.mercurial-scm.org/D1318

py3: handle keyword arguments in hgext/hgk.py Differential Revision: https://phab.mercurial-scm.org/D1317

py3: handle keyword arguments in hgext/graphlog.py Differential Revision: https://phab.mercurial-scm.org/D1316

merge with stable

Added signature for changeset cabc840ffdee

Added tag 4.4.1 for changeset cabc840ffdee

templatekw: add verbosity keyword to select template by -q/-v/--debug flag This can be used in conjunction with the ifeq() function.

templatekw: move loadkeyword() to bottom loadkeyword() isn't a template keyword function.

help: hide phaseidx template keyword I don't think it's great idea to expose the internal representation of phases. Let's discourage use of the phaseidx keyword.

stable: merge with security patches

subrepo: use per-type config options to enable subrepos We change subrepos.allowed from a list of allowed subrepo types to a combination of a master switch and per-type boolean flag. If the master switch is set, subrepos can be disabled wholesale. If subrepos are globally enabled, then per-type options are consulted. Mercurial repos are enabled by default. Everything else is disabled by default.

config: add some more documentation around why svn and git subrepos are off

subrepo: disable git and svn subrepos by default (BC) (SEC) We have a security issue with git subrepos. I'm not sure if svn subrepo is vulnerable, but it seems not 100% safe to allow writing arbitrary data into a metadata directory. So for now, only hg subrepo is enabled by default. Maybe we should improve the help to describe why git/svn subrepos are disabled.

subrepo: extend config option to disable subrepos by type (SEC) This allows us to minimize the behavior change introduced by the next patch. I have no idea which config style is preferred in UX POV, but I decided to get things done. a) list: 'allowed = hg, git, svn' b) sub option: 'allowed.hg = True' or 'allowed:hg = True' c) per-type action: 'hg = allow', 'git = abort'

subrepo: add config option to reject any subrepo operations (SEC) This is an alternative workaround for the issue5730. Perhaps this is the simplest way of disabling subrepo operations. It does nothing clever, but just aborts if Mercurial starts accessing to a subrepo. I think Greg's patch is more useful since it allows us to at least check out the parent repository. However, that would be confusing if the default is flipped to checkout=False and subrepos are silently ignored. I don't like the config name 'allowed', but I couldn't get any better name.

subrepo: disallow symlink traversal across subrepo mount point (SEC) It wasn't easy to extend the pathauditor to check symlink traversal across subrepos because pathauditor._checkfs() rejects a directory having ".hg" directory. That's why I added the explicit islink() check. No idea if this patch is necessary after we've fixed the issue5730 by splitting submerge() into planning and execution phases.

tests: show symlink traversal across subrepo mount point (SEC) Also adds a couple of tests where the auditor does work as expected.

share: move config item declarations into core These config items control share behavior that is implemented in core. Since the functionality is implemented in core, extensions may leverage it. Mozilla has one such extension. And, it needs to access share.pool. Before this patch, a devel warning regarding accessing an unregistered config option would be issued unless the share extension were loaded. Moving the registration of the config options to core fixes this.

morestatus: don't crash with different drive letters for repo.root and CWD Previously, if there were unresolved files and the CWD drive was different from the repo drive, `hg status -v` would page the normal status, followed by the exception header. A stacktrace was waiting when the pager exited. The underlying cause was the same as f445b10dc7fb. Unfortunately, I don't see any reasonable way to write a test this [1]. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/107401.html