revset: do not compute weight for integer literal argument In x^n and x~n, n isn't a set expression. There's no need to optimize the right-hand side.

templatekw: export ui.paths as {peerpaths} It's sometimes useful to show hyperlinks in log output. "{get(peerpaths, "default")}/rev/{node}" Since each path may have sub options, "{peerpaths}" is structured as a dict of dicts, but the inner dict is rendered as if it were a string URL. The implementation is ad-hoc, so there are some weird behaviors described in the test. We might need to introduce a proper way of handling a hybrid scalar object. This patch adds _hybrid.__getitem__() so d['path']['url'] works. The keyword is named as "peerpaths" since "paths" seemed too generic in log context.

summary: fix type of empty unresolved list It was okay because tested as a boolean prior to calling len(), but looked incorrect.

vfs: rename auditvfs to proxyvfs Since we've removed mustaudit property, auditvfs has no auditing business. It's just a utility class for vfs wrappers.

streamclone: comment why path auditing is disabled in generatev1() Copied from 39c6e349dfff. I wasn't sure whether it's for optimization or suppressing unwanted error.

streamclone: close large revlog files explicitly in generatev1()

bundle2: no longer use 'retractboundary' in updatephases The new 'phase-heads' forced all added node to secret before advancing the boundary to work around the fact changesets were added as draft by default. This is no longer necessary since the changegroup part can now use the 'targetphase' parameter. Not doing this retract boundary call has a couple of advantages: * This makes implementing phases change tracking in the transaction much simpler since retract boundary can become a rare case. * Bundling secret changesets is not the norm. Exchange never does that and even for strip, the use-case is not common.Skipping the retract boundary will avoid useless work here. * Sending phase update on push can be simplified since we can rely on the behavior of 'cg.apply' for most of it. This means less phases update send for example. * We no longer needs to track and use the addednodes during unbundling. This make it possible to have multiple 'changegroup' and 'phase-heads' parts in the same bundle without them interfering with each others. The new part has not been part of any release yet so we do not offer backward compatibility yet. It is important to update this semantic before the 4.3 freeze happens.

bundle2: automatically add 'targetphase' parameter in writenewbundle If we are bundling secret changeset and the bundle will contain phase, we request the changegroup to be applied as secret. It will be useful for next patch as we are now sure that secrets changesets are applied as secret and not applied as draft then forced to secret.

bundle2: support the 'targetphase' parameter for the changegroup part By default unbundled changesets are drafts. We want to reduce the number of phases changes during unbundling by giving the possibility to the bundle to indicate the phase of unbundled changesets. The longer terms goal is to add phase movement tracking in tr.changes and the 'retractboundary' call is making it more complicated than we want.

changegroup: stop treating strip as special when dealing with phases Since 8e3021fd1a44, the strip bundle includes the phases of the stripping node. Hence we don't need this special case anymore. Dropping it will helps make the phase behavior more consistent across all exchanges medium.

match: inverse _anypats(), making it _prefix()

amend: new extension providing the amend command Various third parties have implemented the `amend` command, which is in high demand. This patch adds it as an experimental extension so its interface could be formalized in core directly. Since `commit --amend` is basically what `amend` should do. The command is just a thin wrapper around `commit --amend` and just prevent the editor from popping up by passing `--message`.

py3: make localrepo filtered repo cache work on py3 I don't know if this is the right fix, but it makes test-py3-commands.t pass again. Differential Revision: https://phab.mercurial-scm.org/D56

configitems: register the 'bugzilla.host' config

configitems: register the 'bugzilla.fixstatus' config

configitems: register the 'bugzilla.fixresolution' config

configitems: register the 'bugzilla.fixregexp' config

configitems: register the 'bugzilla.db' config

configitems: register the 'bugzilla.bzuser' config

configitems: register the 'bugzilla.bzurl' config

configitems: register the 'bugzilla.bzemail' config

configitems: register the 'bugzilla.bzdir' config

configitems: register the 'bugzilla.apikey' config

revlog: use struct.Struct instances for slight performance wins Differential Revision: https://phab.mercurial-scm.org/D32

revlog: micro-optimize the computation of hashes Differential Revision: https://phab.mercurial-scm.org/D31

hgweb: re-implement followlines UI selection using buttons This changeset attempts to solve two issues with the "followlines" UI in hgweb. First the "followlines" action is currently not easily discoverable (one has to hover on a line for some time, wait for the invite message to appear and then perform some action). Second, it gets in the way of natural line selection, especially in filerevision view. This changeset introduces an additional markup element (a <button class="btn-followlines">) alongside each content line of the view. This button now holds events for line selection that were previously plugged onto content lines directly. Consequently, there's no more action on content lines, hence restoring the "natural line selection" behavior (solving the second problem). These buttons are hidden by default and get displayed upon hover of content lines; then upon hover of a button itself, a text inviting followlines section shows up. This solves the first problem (discoverability) as we now have a clear visual element indicating that "some action could be perform" (i.e. a button) and that is self-documented. In followlines.js, all event listeners are now attached to these <button> elements. The custom "floating tooltip" element is dropped as <button> elements are now self-documented through a "title" attribute that changes depending on preceding actions (selection started or not, in particular). The new <button> element is inserted in followlines.js script (thus only visible if JavaScript is activated); it contains a "+" and "-" with a "diff-semantics" style; upon hover, it scales up. To find the parent element under which to insert the <button> we either rely on the "data-selectabletag" attribute (which defines the HTML tag of children of class="sourcelines" element e.g. <span> for filerevision view and <tr> for annotate view) or use a child of the latter elements if we find an element with class="followlines-btn-parent" (useful for annotate view, for which we have to find the <td> in which to insert the <button>). On noticeable change in CSS concerns the "margin-left" of span:before pseudo-elements in filelog view that has been increased a bit in order to leave space for the new button to appear between line number column and line content one. Also note the "z-index" addition for "annotate-info" box so that the latter appears on top of new buttons (instead of getting hidden). In some respect, the UI similar to line commenting feature that is implemented in popular code hosting site like GitHub, BitBucket or Kallithea.

localrepo: cache types for filtered repos (issue5043) Python introduces a reference cycle on dynamically created types via __mro__, making them very easy to leak. See https://bugs.python.org/issue17950. Previously, repo.filtered() created a type on every invocation. Long-running processes (like `hg convert`) could call this function thousands of times, leading to a steady memory leak. Since we're Unable to stop the leak because this is a bug in Python, the next best thing is to contain it. This patch adds a cache of of the dynamically generated repoview/filter types on the localrepo object. Since we only generate each type once, we cap the amount of memory that can leak to something reasonable. After this change, `hg convert` no longer leaks memory on every revision. The process will likely grow memory usage over time due to e.g. larger manifests. But there are no leaks.

convert: transcode CVS log messages by specified encoding (issue5597) Converting from CVS to Mercurial assumes that CVS log messages in "cvs rlog" output are encoded in UTF-8 (or basic Latin-1). But cvs itself is usually unaware of encoding of log messages, in practice. Therefore, if there are commits, of which log message is encoded in other than UTF-8, log message of corresponded revisions in the converted repository will be broken. To avoid such broken log messages, this patch transcodes CVS log messages by encoding specified via "convert.cvsps.logencoding" configuration. This patch accepts multiple encoding for convenience, because "multiple encoding mixed in a repository" easily occurs. For example, UTF-8 (recent POSIX), cp932 (Windows), and EUC-JP (legacy POSIX) are well known encoding for Japanese.

fsmonitor: execute setup procedures only if dirstate is already instantiated Before this patch, reposetup() of fsmonitor executes setup procedures for dirstate, even if it isn't yet instantiated at that time. On the other hand, dirstate might be already instantiated before reposetup() intentionally (prefilling by chg, for example, see bf3af0eced44 for detail). If so, just discarding already instantiated one in reposetup() causes issue. To resolve both issues above, this patch executes setup procedures, only if dirstate is already instantiated. BTW, this patch removes "del repo.unfiltered().__dict__['dirstate']", because it is responsibility of the code path, which causes instantiation of dirstate before reposetup(). After this patch, using localrepo.isfilecached() should avoid creating the corresponded entry in repo.unfiltered().__dict__.

fsmonitor: centralize setup procedures for dirstate