merge: return an attrs class from update() and applyupdates() Previously, we returned a tuple containing counts. The result of an update is kind of complex and the use of tuples with nameless fields made the code a bit harder to read and constrained future expansion of the return value. Let's invent an attrs-defined class for representing the result of an update operation. We provide __getitem__ and __len__ implementations for backwards compatibility as a container type to minimize code churn. In (at least) Python 2, the % operator seems to insist on using tuples. So we had to update a consumer using the % operator. .. api:: merge.update() and merge.applyupdates() now return a class with named attributes instead of a tuple. Switch consumers to access elements by name instead of by offset. Differential Revision: https://phab.mercurial-scm.org/D2692

histedit: make histedit's commands accept revsets (issue5746) Earlier the code was only looking for rulehashes and neglecting all other revision identifiers, this code intercepts the fromrule function and calls scmutil.revsingle() on anything that is not a rulehash and then obtains the rulehash from the changectx object returned, rest of the pipeline follows as it was Differential Revision: https://phab.mercurial-scm.org/D2394

formatter: make 'originalnode' a thing in log-like templates mapping['node'] doesn't work since {node} is computed dynamically in non-web templates.

formatter: port handling of 'originalnode' to populatemap() hook This isn't a pure templating business, so let's move out of the templater module. Note that this works only in web templates where mapping['node'] is a static value.

templater: switch 'revcache' based on new mapping items It was pretty easy to leave a stale 'revcache' when switching 'ctx'. Let's make it be automatically replaced.

templater: add hook point to populate additional mapping items The 'revcache' dict will be inserted by this hook.

context: skip path conflicts by default when clearing unknown file (issue5776) Prior to adding path conflict checking in 989e884d1be9, the test-audit-path.t tests failed as shown here (but it was globbed away). 989e884d1be9 made it fail with a message about the destination manifest containing a conflict (though the no-symlink case wasn't updated). When the path conflict checking was gated behind an experimental config in 2a774cae3a03^::2a774cae3a03, the update started erroneously succeeding here. It turns out that the child of 989e884d1be9 is the origin of this change when path conflict checking is disabled, as shown by grafting the experimental config range on top of it. What's happening here is merge.batchget() is writing the symlink 'back' to wdir (but as a regular file for the no-symlink case), and then tries to write 'back/test', but calls wctx['back/test'].clearunknown() first. The code that's gated here was removing the newly written 'back' file, allowing 'back/test' to succeed. I tried checking for the dir components of 'back/test' in dirstate, and skipping removal if present. But that didn't work because the dirstate isn't updated after each file is written out. This is the last persistent test failure on Windows, so the testbot should start turning green now. \o/

url: make logginghttphandler compatible with Python 2.7.6 There wasn't a usable hook point in httplib, so we have to replace connect() to wrap the socket before self._tunnel().

util: make safehasattr() a pycompat function So safehasattr() can be imported by utils.* modules. util.safehasattr() still remains as an alias since it is pretty basic utility available for years. On current Python 3, the builtin hasattr() should have no problem.

util: drop util.Abort in favor of error.Abort (API) IIRC, error.Abort exists since Mercurial 1.2, so it should be pretty easy for extensions authors to update their code. .. api:: The util.Abort alias has been removed. Use error.Abort.

test-bundle2-exchange: use error.Abort instead of util.Abort

util: use error.Abort instead of local alias

rcutil: directly call win32.executablepath() Since it isn't supported on POSIX platform, we don't need to double the compatibility layers.

directaccess: do not abort by 'ff...' hash Since the 'ff...' hash should never be hidden, we can just ignore it.

hgweb: don't responsd to api requests unless feature is enabled Per discussion at https://phab.mercurial-scm.org/D2834, new URLs in hgweb can conflict with subrepos and virtual repos. This may prevent access to repos in certain paths or having certain names. Until we have a workaround for this, let's not serve requests for "api/" URLs unless the feature is enabled. Differential Revision: https://phab.mercurial-scm.org/D2936

fancyopts: prevent mutation of the default value in customopts Differential Revision: https://phab.mercurial-scm.org/D2937

fancyopts: fix rendering of customopt defaults in help text Differential Revision: https://phab.mercurial-scm.org/D2935

remotenames: show remote bookmarks in `hg bookmarks` This patch adds functionality to show list of remote bookmarks in `hg bookmarks` command. There is some indenting problem in the test output as the current bookmark printing code in core can handle bookmark names of size 25 only gracefully. The idea is taken from hgremotenames extension which has --remote and --all flags to show remote bookmarks. However, this patch by defaults support showing list of remote bookmarks if remotenames extension is enabled and remotebookmarks are turned on. Differential Revision: https://phab.mercurial-scm.org/D2808

remotenames: add functionality to hoist remotebookmarks This patch adds the functionality to hoist remotebookmarks to the top level namespace. The peer of which bookmarks should be hoisted can be set using `remotenames.hoistedpeer` config option. Only bookmarks can be hoisted. If a hoisted name and local bookmark exists of the same name, the local bookmark takes precedence. While I was here, I documented the default values of two other remotenames config options. Differential Revision: https://phab.mercurial-scm.org/D2807

copyfile: preserve stat info (mtime, etc.) when doing copies/renames Differential Revision: https://phab.mercurial-scm.org/D2729

merge: add 'isknown=True' to a dirstate.normalize() in _unknowndirschecker Per the docstring for dirstate.normalize().

merge: pconvert paths in _unknowndirschecker before dirstate-normalizing This fixes the failure in test-pathconflicts-basic.t on Windows. The test was passing in 'a\b', which was getting normalized to 'A\B', which isn't in dirstate. (The filesystem path is all lowercase anyway.) This isn't the only case of calling dirstate.normalize(), but other methods here (util.finddirs()) seem to assume the input paths are already using '/'. I think the backslash comes from wvfs.reljoin() (in this case), but could also come from wvfs.walk(), so this is the only case that needs it.

util: enable deprecation warning for stringutil proxy (API) .. api:: Several generic string helper functions have been moved to utils.stringutil module.

stringutil: bulk-replace call sites to point to new module This might conflict with other patches floating around, sorry.

stringutil: move generic string helpers to new module Per https://phab.mercurial-scm.org/D2903#46738 URL and file paths functions are left since they are big enough to make separate modules.

util: remove unused private constant '_hextochr' The only user, _urlunquote(), was removed by 81d38478fced.

util: mark internal constants of escapedata() as private

util: adjust indent level in wrap()

util: mark MBTextWrapper as private Makes porting slightly easier.

util: add helper to define proxy functions to utils.*

filemerge: make the 'local' path match the format that 'base' and 'other' use If we pass a separate '$output' arg to the merge tool, we produce four files: local, base, other, and output. In this situation, 'output' will be the original filename, 'base' and 'other' are temporary files, and previously 'local' would be the backup file (so if 'output' was foo.txt, 'local' would be foo.txt.orig). This change makes it so that 'local' follows the same pattern as 'base' and 'other' - it will be a temporary file either in the `experimental.mergetempdirprefix`-controlled directory with a name like foo~local.txt, or in the normal system-wide temp dir with a name like foo~local.RaNd0m.txt. For the cases where the merge tool does not use an '$output' arg, 'local' is still the destination filename, and 'base' and 'other' are unchanged. The hope is that this is much easier for people to reason about; rather than having a tool like Meld pop up with three panes, one of them with the filename "foo.txt.orig", one with the filename "foo.txt", and one with "foo~other.StuFf2.txt", we can (when the merge temp dir stuff is enabled) make it show up as "foo~local.txt", "foo.txt" and "foo~other.txt", respectively. This also opens the door to future customization, such as getting the operation-provided labels and a hash prefix into the filenames (so we see something like "foo~dest.abc123", "foo.txt", and "foo~src.d4e5f6"). Differential Revision: https://phab.mercurial-scm.org/D2889

test-strip-narrow: adjust bundle removal for Windows test stability MSYS was mangling $TESTTMP to C:\\Users\\...\\test-narrow-strip.t-flat/, which caused `rm` to fail. The -f was suppressing -ENOENT, so the only clue something was wrong was when 2 bundles were applied via `hg unbundle` on line 91, instead of just 1. This changed the text output of `hg unbundle`. The first `rm` wasn't causing an issue, but is changed for consistency with the rest of the file.

templater: drop symbols which should be overridden by new 'ctx' (issue5612) This problem is caused by impedance mismatch between the templater and the formatter interface, which is that the template keywords are generally evaluated dynamically, but the formatter puts static values into a template mapping. This patch avoids the problem by removing conflicting values from a mapping dict when a 'ctx' is switched.

templater: factor out function to create mapping dict for nested evaluation overlaymap() is the hook point to drop mapping items conflicting with the default keywords which have to be re-evaluated with new 'ctx' resource.

templater: introduce resourcemapper class A couple more functions will be added later to work around nested mapping bugs such as the issue 5612.

log: do no expect templateresources() returning a dict The resources dict will be replaced with new resource mapper object, which won't implement __getitem__(key). Share the whole resources object with _graphnodeformater() to make porting easier.

templatekw: mark _showlist() as deprecated (API) .. api:: ``templatekw._showlist()`` is deprecated in favor of ``templateutil._showcompatlist()``, which takes ``context`` in place of ``templ``.

templater: drop 'templ' from resources dict Partially resolves cycle, templ -> context -> templ. This will make it easier to replace the resources dict with new immutable resource mapper interface.

templatekw: stop using _showlist() which is about to be deprecated Use the new context-based API instead.

templater: use template context to render old-style list template Prepares for dropping the 'templ' resource. This means old-style list templates are processed by the same engine class as the one for the list node. I think that's fine since templates for the same list should be tightly coupled, and I believe the extension point for the engine classes isn't actually used. Now templatekw._showlist() is a compatibility wrapper for _showcompatlist(), and will be deprecated soon. The function is still marked as private since I plan to change the interface to get rid of closures capturing context and mapping.

templater: add context.preload(t) to test if the specified template exists I'm going to remove 'templ' from the resources dict because it is the only resource that the caller can't provide. This also implies that putting 'templ' into the resources dict creates a reference cycle. context.preload(t) will be used in place of templater.__contains__().

annotate: pack line content into annotateline object (API) Just for code readability. We can do that since the annotateline type is no longer used while computing the history.

annotate: drop linenumber flag from fctx.annotate() (API) Now linenumber=True is fast enough to be enabled by default.

annotate: do not construct attr.s object per line while computing history Unfortunately, good abstraction has a cost. It's way slower to construct an annotateline() object than creating a plain tuple or a list. This patch changes the internal data structure from row-based to columnar, so the decorate() function can be instant (i.e. no Python in hot loop.) For code readability, the outermost tuple is switched to an attr.s object instead. (original, row-based attr.s) $ hg annot mercurial/commands.py --time > /dev/null time: real 11.470 secs (user 11.400+0.000 sys 0.070+0.000) $ hg annot mercurial/commands.py --time --line-number > /dev/null time: real 39.590 secs (user 39.500+0.000 sys 0.080+0.000) (this patch, columnar) $ hg annot mercurial/commands.py --time > /dev/null time: real 11.780 secs (user 11.710+0.000 sys 0.070+0.000) $ hg annot mercurial/commands.py --time --line-number > /dev/null time: real 12.240 secs (user 12.170+0.000 sys 0.090+0.000) (cf. 4.3.3, row-based tuple) $ hg annot mercurial/commands.py --time --line-number > /dev/null time: real 19.540 secs (user 19.460+0.000 sys 0.080+0.000)

wireproto: explicitly track which requests are active We previously only tracked which requests are receiving. A misbehaving client could accidentally have multiple requests with the same ID in flight. We now explicitly track which request IDs are currently active. We make it illegal to receive a frame associated with a request ID that has already been dispatched. Differential Revision: https://phab.mercurial-scm.org/D2901

wireproto: use named arguments when passing around frame data Named arguments is easier to reason about compared to positional arguments. Especially when you have many positional arguments. Differential Revision: https://phab.mercurial-scm.org/D2900

wireproto: define attr-based classes for representing frames When frames only had 3 attributes, it was reasonable to represent them as a tuple. With them growing more attributes, it will be easier to pass them around as a more formal type. So let's define attr-based classes to represent frame headers and full frames. Differential Revision: https://phab.mercurial-scm.org/D2899

wireproto: define human output side channel frame Currently, the SSH protocol delivers output tailored for people over the stderr file descriptor. The HTTP protocol doesn't have this file descriptor (because it only has an input and output pipe). So it encodes textual output intended for humans within the protocol responses. So response types have a facility for capturing output to be printed to users. Some don't. And sometimes the implementation of how that output is conveyed is super hacky. On top of that, bundle2 has an "output" part that is used to store output that should be printed when this part is encountered. bundle2 also has the concept of "interrupt" chunks, which can be used to signal that the regular bundle2 stream is to be preempted by an out-of-band part that should be processed immediately. This "interrupt" part can be an "output" part and can be used to print data on the receiver. The status quo is inconsistent and insane. We can do better. This commit introduces a dedicated frame type on the frame-based protocol for denoting textual data that should be printed on the receiver. This frame type effectively constitutes a side-channel by which textual data can be printed on the receiver without interfering with other in-progress transmissions, such as the transmission of command responses. But wait - there's more! Previous implementations that transferred textual data basically instructed the client to "print these bytes." This suffered from a few problems. First, the text data that was transmitted and eventually printed originated from a server with a specic i18n configuration. This meant that clients would see text using whatever the i18n settings were on the server. Someone in France could connect to a server in Japan and see unlegible Japanese glyphs - or maybe even mojibake. Second, the normalization of all text data originated on servers resulted in the loss of the ability to apply formatting to that data. Local Mercurial clients can apply specific formatting settings to individual atoms of text. For example, a revision can be colored differently from a commit message. With data over the wire, the potential for this rich formatting was lost. The best you could do (without parsing the text to be printed), was apply a universal label to it and e.g. color it specially. The new mechanism for instructing the peer to print data does not have these limitations. Frames instructing the peer to print text are composed of a formatting string plus arguments. In other words, receivers can plug the formatting string into the i18n database to see if a local translation is available. In addition, each atom being instructed to print has a series of "labels" associated with it. These labels can be mapped to the Mercurial UI's labels so locally configured coloring, styling, etc settings can be applied. What this all means is that textual messages originating on servers can be localized on the client and richly formatted, all while respecting the client's settings. This is slightly more complicated than "print these bytes." But it is vastly more user friendly. FWIW, I'm not aware of other protocols that attempt to encode i18n and textual styling in this manner. You could lobby the claim that this feature is over-engineered. However, if I were to sit in the shoes of a non-English speaker learning how to use version control, I think I would *love* this feature because it would enable me to see richly formatted text in my chosen locale. Anyway, we only implement support for encoding frames of this type and basic tests for that encoding. We'll still need to hook up the server and its ui instance to emit these frames. I recognize this feature may be a bit more controversial than other aspects of the wire protocol because it is a bit "radical." So I'd figured I'd start small to test the waters and see if others feel this feature is worthwhile. Differential Revision: https://phab.mercurial-scm.org/D2872