help: do not abort topicmatch() because of unimportable extensions This is alternative workaround to D1198, originally spotted by the earlier version of the releasenotes extension.

configitems: register 'email.to' and 'patchbomb.to'

exchange: propagate the subfunctions return The parts generator can return a callback to handle server reply. We should propagate the return for correctness.

merge default into stable for code freeze # no-check-commit because default contains new vendored code

log: add an assertion about fctx not being None in patch.diff() As noted in the comment, this should not happen as removed files (the cause of fctx2 being None) are caught earlier.

log: handle removed files with --line-range patterns I.e. abort when the pattern corresponds to a removed file, as done with bare file patterns.

log: disable bare file patterns with --line-range Currently, specifying both a line-range pattern and a bare file pattern results in an AND operation whereas we probably want an OR so that bare file patterns are like a line-range pattern with all lines specified. So, until this works as expected, we disable this.

log: switch to FROMLINE:TOLINE syntax for -L/--line-range This is more consistent with the followlines() revset.

log: handle binary files in --line-range patterns When a file is binary patch.trydiff() would yield None for 'hunkrange'. Handle this case in the hunksfilter() callback. Add tests with and without diff.git option as binary handling differs depending on this option's value.

build: build deb/rpm independently on config/extensions in the host system Reverts 5aac617a028d and replaces it with a more general solution. - works for both rpm and deb - sidesteps eventual problems with local extensions that have nothing to do with the build process (hg-git, for example, fails with version 4.4 because dedab036215d removed peerrepository, and hg-git still uses it as of 0.8.9)

config: also gather effect-flags on experimental.evolution Effect-flags config was in flight while the previous evolve config renaming was written. Now that both landed, gather effect-flags in experimental.evolution like the others evolve-related configurations. Differential Revision: https://phab.mercurial-scm.org/D1197

obsfate: rename obsfate into obsolete in default mapfile Like the previous patch, replace obsfate by obsolete in default mapfile. Differential Revision: https://phab.mercurial-scm.org/D1190

obsfate: rename obsfate into obsolete in changeset_printer Yuja's comment on the original obsfate about how we would translate obsfate and the recent discussions about exposing users to new concepts and names lead have led me to think that 'obsfate' should be treated as internal jargon. End- users should not be aware of obsfate, so we replace 'obsfate' by 'obsolete' in changeset_printer. It will be easier to understand for end-users, easier to translate and closer to the original Evolve obsfate output. I'm aware it's extremely late in the cycle but I think it's an UX improvement for the end-users. Differential Revision: https://phab.mercurial-scm.org/D1189

tests: add some (?) output lines to catch "helpful" output from Solaris diff Differential Revision: https://phab.mercurial-scm.org/D1196

sparse-read: ignore trailing empty revs in each read chunk An empty entry in the revlog may happen for two reasons: - when the file is empty, and the revlog stores a snapshot; - when there is a merge and both parents were identical. `hg debugindex -m | awk '$3=="0"{print}' | wc -l` gives 1917 of such entries in my clone of pypy, and 113 on my clone of mercurial. These empty revision may be located at the end of a sparse chain, and in some special cases may lead to read relatively large amounts of data for nothing.

fsmonitor: use nonnormalset from dirstatemap `dirstate._nonnormalset` has been moved to `dirstate._map.nonnormalset` by 60927b19ed65 (dirstate: move nonnormal and otherparent sets to dirstatemap) and is guaranteed to be existed. Let's update fsmonitor code to use the new `nonnormalset`. Thix fixed a perf regression that slows down `hg status` by 0.5 seconds in one of our production repos. Differential Revision: https://phab.mercurial-scm.org/D1184

registrar: don't i18n ProgrammingError message Differential Revision: https://phab.mercurial-scm.org/D1188

registrar: move "constant" possiblecmdtypes to class level While at it, switch to set literal syntax. Differential Revision: https://phab.mercurial-scm.org/D1187

tests: de-flake test-run-tests.t's "--jobs=2 --first" test Once in a while, test-nothing.t finished before test-failure.t or test-failure-copy.t (I haven't checked which one actually gets run first). Since there already are two tests that will fail in the same way, just run those two instead so the diff will be reproducible and not timing-dependent. The test case was added in 9a20f53e436f (run-tests: handle --jobs and --first gracefully, 2014-10-09), and I have checked that backing that out results in two failures being printed. Note that the summary may still include multiple tests even if --first is given, it's just that the diff is only printed for the first failure. Differential Revision: https://phab.mercurial-scm.org/D1186

cmdutil: fix status tersing on Python 3 Differential Revision: https://phab.mercurial-scm.org/D1183

hghave: fix clang-format check to use bytes regex Fixes hghave on Python 3. Differential Revision: https://phab.mercurial-scm.org/D1182

configitems: make all regular expressions bytes and not native str Fixes many tests on Python 3. Differential Revision: https://phab.mercurial-scm.org/D1181

convert: register missed subversion config items Should fix the build failures on the Solaris builders. Differential Revision: https://phab.mercurial-scm.org/D1180

amend: error out if the note is greater than 255bytes In obsmarker we can't store keys and values of more than 255 bytes in metadata. If we try to do so, ProgrammingError is raised. The note flag to amend stores the note in obsmetadata. If a user will try to store a larger note, he will encounter ProgrammingError which is wrong. We must error out early. Thanks to Yuya for warning about this. Differential Revision: https://phab.mercurial-scm.org/D1179

show: move configitems to core chgserver.py is also checking the config and will get: devel-warn: accessing unregistered config item: 'commands.show.aliasprefix' at: mercurial/chgserver.py:109 if the config is not registered. Differential Revision: https://phab.mercurial-scm.org/D1178

chgserver: do not treat HG as sensitive environ when CHGHG is set When `$CHGHG` is set, `$HG` is ignored by the chg client. Removing it from chg's sensitive environment list would avoid starting up servers unnecessarily when `$CHGHG` is the same while `$HG` is different. Differential Revision: https://phab.mercurial-scm.org/D1177

fsmonitor: declare missing config options These were added in 4aa57627692a. Attempting to run the test harness with fsmonitor enabled spews a whole bunch of devel warnings due to these options not be declared. Differential Revision: https://phab.mercurial-scm.org/D1176

fsmonitor: warn when fsmonitor could be used fsmonitor can significantly speed up operations on large working directories. But fsmonitor isn't enabled by default, so naive users may not realize there is a potential to make Mercurial faster. This commit introduces a warning to working directory updates when fsmonitor could be used. The following conditions must be met: * Working directory is previously empty * New working directory adds >= N files (currently 50,000) * Running on Linux or MacOS * fsmonitor not enabled * Warning not disabled via config override Because of the empty working directory restriction, most users will only see this warning during `hg clone` (assuming very few users actually do an `hg up null`). The addition of a warning may be considered a BC change. However, clone has printed warnings before. Until recently, Mercurial printed a warning with the server's certificate fingerprint when it wasn't explicitly trusted for example. The warning goes to stderr. So it shouldn't interfere with scripts parsing meaningful output. The OS restriction was on the advice of Facebook engineers, who only feel confident with watchman's stability on the supported platforms. .. feature:: Print warning when fsmonitor isn't being used on a large repository Differential Revision: https://phab.mercurial-scm.org/D894

merge: additional test cases to show merge-halting behavior In the previous patches, we allowed the user to specify that a merge process should be halted when a filemerge fails. This patch adds tests that show additional places this logic can be utilized -- via the options to do additional post-filemerge checks to determine if a file merge was successful. Differential Revision: https://phab.mercurial-scm.org/D952

rebase: add support to output nodechanges This patch adds support to rebase to show the changes in node once the rebase is complete. This will be extremely helpful for automation purposes and editors such as Nuclide. The output is a dictionary of predecessor hash as key and a list of successors' hashes. The successors one is a list as there can be many successors for a single predecessor in case of split and it will good to have a generic output format. This patch adds tests for the same. A new file is created for the patch as existing files related to rebase has their own purpose and there will be more formatter support coming for rebase in next cycle. Thanks to Jun for suggesting to use fm.data(). Differential Revision: https://phab.mercurial-scm.org/D1173

ui: move request exit handlers to global state Since the ui objects can be created with the 'load' class method, it is possible to lose the exit handlers information from the old ui instance. For example, running 'test-bad-extension.t' leads to this situation where chg creates a new ui instance which does not copy the exit handlers from the earlier ui instance. For exit handlers, which are special cases anyways, it probably makes sense to have a global state of the handlers. This would ensure that the exit handlers registered once are definitely executed at the end of the request. Test Plan: Ran all the tests without '--chg' option. This also fixes the 'test-bad-extension.t' with the '--chg' option. Differential Revision: https://phab.mercurial-scm.org/D1166

sparse-read: skip gaps too small to be worth splitting Splitting at too small gaps might not be worthwhile. With this changeset, we stop considering splitting on too small gaps. The threshold is configurable. We arbitrarily pick 256K as a default value because it seems "okay". Further testing on various repositories and setups will be needed to tune it. The option name is 'experimental.sparse-read.min-gap-size`, and replaces `experimental.sparse-read.min-block-size` which is not used any more.

sparse-read: move from a recursive-based approach to a heap-based one The previous recursive approach was trying to optimise each read slice to have a good density. It had the tendency to over-optimize smaller slices while leaving larger hole in others. The new approach focuses on improving the combined density of all the reads, instead of the individual slices. It slices at the largest gaps first, as they reduce the total amount of read data the most efficiently. Another benefit of this approach is that we iterate over the delta chain only once, reducing the overhead of slicing long delta chains. On the repository we use for tests, the new approach shows similar or faster performance than the current default linear full read. The repository contains about 450,000 revisions with many concurrent topological branches. Tests have been run on two versions of the repository: one built with the current delta constraint, and the other with an unlimited delta span (using 'experimental.maxdeltachainspan=0') Below are timings for building 1% of all the revision in the manifest log using 'hg perfrevlogrevisions -m'. Times are given in seconds. They include the new couple of follow-up changeset in this series. delta-span standard unlimited linear-read 922s 632s sparse-read 814s 566s

subrepo: implement 'unshare' for Mercurial subrepos I think there's a slight hole here in that a subrepo could be shared, removed from .hgsub, and then it's not part of context.substate (so not iterated over). But the push command has the same hole IIRC, and I think removing a subrepo is an edge case. The import hack is a copy/paste of subrepo.subrepo().

share: move the implementation of 'unshare' to the 'hg' module This will be used to setup unsharing subrepos. Usually cmdutil is used for this purpose. But the implementation needs hg.copystore(), and the hg module already imports cmdutil.

show: use labelcset() template alias for work (and stack) views By reusing labelcset() template alias from map-cmdline.default we can now display obsolescence information in `hg show work/stack`.

phases: pass phase names to hooks instead of internal values

configitems: document the choice of using 'match' instead of 'search'

configitems: do not directly match generic items Before this changesets, a literal '.*:foo$' config would match a registered '.*:foo$' generic. This is wrong since generic should be matched through regular exception only. This changeset fixes this problem. Thanks for to Yuya Nishihara for spotting the issue.

obsfate: fix obsfate_printer with empty date list When the list of dates is empty, `min` and `max` would raises a ValueError. Protect against this case by checking that the date list is not empty. I didn't add a test because I couldn't find a reproducing test case.

config: gather allowdivergence under the evolution namespace Grouping all evolution related-config under the experimental.evolution namespace would helps the future migration outside [experimental]. Differential Revision: https://phab.mercurial-scm.org/D1155

config: remove stabilization.* aliases Stabilization config items were never part of a release, remove them now that we cleaned up the evolution related configuration. Differential Revision: https://phab.mercurial-scm.org/D1154

config: rename stabilization.track-operation We want to get rid of stabilization.* configuration, back out to the old configuration 'evolution.track-operation'. Differential Revision: https://phab.mercurial-scm.org/D1153

config: rename stabilization.bundle-obsmarker We want to get rid of stabilization.* configuration, back out to the old configuration 'evolution.bundle-obsmarker'. Differential Revision: https://phab.mercurial-scm.org/D1152

config: use 'experimental.evolution.exchange' Extract 'experimental.evolution' = exchange as 'experimental.evolution.exchange'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.exchange'. Differential Revision: https://phab.mercurial-scm.org/D1151

config: use 'experimental.evolution.allowunstable' Extract 'experimental.evolution' = allowunstable as 'experimental.evolution.allowunstable'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.allowunstable'. Differential Revision: https://phab.mercurial-scm.org/D1150

config: use 'experimental.evolution.create-markers' Extract 'experimental.evolution' = createmarkers as 'experimental.evolution.createmarkers'. We keep the new option in the 'experimental.evolution' namespace in order to stay coherent with other options ('experimental.evolution.bundle-obsmarker' and 'experimental.evolution.track-operation') ease the renaming as possibly 'evolution.createmarkers'. Differential Revision: https://phab.mercurial-scm.org/D1149

config: replace experimental.stabilization by experimental.evolution We replace 'experimental.stabilization=all' by 'experimental.evolution=true' as we will extract individual config in their own config in later patches. Differential Revision: https://phab.mercurial-scm.org/D1148

config: update evolution-related config Update the evolution helpers function to support both old-style configuration and new-style configuration: experimental.evolution=all is renamed into experimental.evolution=true experimental.evolution=createmarkers is renamed into experimental.evolution.createmarkers=true experimental.evolution=allowunstable is renamed into experimental.evolution.allowunstable=true experimental.evolution=exchange is renamed into experimental.evolution.exchange=true We choose to not rename individual config options; keeping the same names would easy the transition for users but it's something that could be easily done in the future. Differential Revision: https://phab.mercurial-scm.org/D1147

config: invert evolution-related configuration aliases We want to split the evolution-related configuration and back-out the renaming from evolution.* to stabilization.*. First invert the configuration and aliases, so next changesets will be cleaner. Differential Revision: https://phab.mercurial-scm.org/D1146

parsers: allow clang-format here # skip-blame because parsers.c is mechanically rewritten by clang-format with no semantic change. Differential Revision: https://phab.mercurial-scm.org/D1170

cext: add /* header */ comment to all PyVarObject_HEAD_INIT() calls This gives clang-format the right notion about formatting these struct initializers, therefore allowing us to automatically format several additional files. # skip-blame because this is just a content-free comment addition Differential Revision: https://phab.mercurial-scm.org/D1169

parsers: protect some case-folding tables from clang-format We want a slightly weird format here so that it's easier to read, but in order to preserve that we need to disable clang-format. Differential Revision: https://phab.mercurial-scm.org/D1168

makefile: add target to apply clang-format in-place This makes it easy to reformat files after you finish editing them. Differential Revision: https://phab.mercurial-scm.org/D1167

configitems: adds a developer warning when accessing undeclared configuration Now that all known options are declared, we setup a warning to make sure it will stay this way. We disable the warning in two tests checking other behavior with random options.

log: add -L/--line-range option to follow file history by line range We add an experimental -L/--line-range option to 'hg log' taking file patterns along with a line range using the (new) FILE,FROMLINE-TOLINE syntax where FILE may be a pattern (matching exactly one file). The resulting history is similar to what the "followlines" revset except that, if --patch is specified, only diff hunks within specified line range are shown. Basically, this brings the CLI on par with what currently only exists in hgweb through line selection in "file" and "annotate" views resulting in a file log with filtered patch to only display followed line range. The option may be specified multiple times and can be combined with --rev and regular file patterns to further restrict revisions. Usage of this option requires --follow; revisions are shown in descending order and renames are followed. Only the --graph option is currently not supported. The UI is the result of a consensus from review feedback at: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-October/106749.html The implementation spreads between commands.log() and cmdutil module. In commands.log(), the main loop may now use a "hunksfilter" factory (similar to "filematcher") that, for a given "rev", produces a filtering function for diff hunks for a given file context object. The logic to build revisions from -L/--line-range options lives in cmdutil.getloglinerangerevs() which produces "revs", "filematcher" and "hunksfilter" information. Revisions obtained by following files' line range are filtered if they do not match the revset specified by --rev option. If regular FILE arguments are passed along with -L options, both filematchers are combined into a new matcher. .. feature:: Add an experimental -L/--line-range FILE,FROMLINE-TOLINE option to 'hg log' command to follow the history of files by line range. In combination with -p/--patch option, only diff hunks within specified line range will be displayed. Feedback, especially on UX aspects, is welcome.

diff: pass a diff hunks filter function from changeset_printer to patch.diff() We add a 'hunksfilterfn' keyword argument in all functions of the call stack from changeset_printer.show() to patch.diff(). This is a callable that will be used to filter out hunks by line range and will be used in the "-L/--line-range" option of "hg log" command introduced in the following changesets.

diff: also yield file context objects in patch.trydiff() (API) And retrieve them in patch.diffhunks(). We'll use these in forthcoming changesets to filter diff hunks by line range.

revset: extract a parsefollowlinespattern helper function We'll need the same logic in forthcoming changeset to handle --line-range option in 'hg log' command. The function lives in scmutil.py (rather than util.py) as it uses match and pathutil modules.

obsfate: add obsfate to default mapfile Use the verbosity aware template keyword introduced earlier. It has the nice property of being verbosity dependent but in order to customize the obsfate part, users will need to replace the lobsfate definition from default mapfile with the one using template functions (by copying the one from test-obsmarker- template.t for example). As it's a more advanced use-case, I'm more inclined to have the same code for the {obsfate} keyword, in the changeset printer and in the default mapfile for consistency. But, the definition in default mapfile could be replaced with one based on template filter to obsfate output customization if it is a big need for users.