sparse-revlog: drop unused deltainfo parameter from _slicechunktodensity We no longer need to deal with slicing logic including uncommitted revision. We drop the associated code.

sparse-revlog: skip the span check in the sparse-revlog case This significantly improves the performance on unbundling on smaller repositories. Mercurial: unbundling 1K revisions no-sparse-revlog: 500 ms sparse-revlog-before: 689 ms sparse-revlog-after: 484 ms Pypy: unbundling 1K revisions no-sparse-revlog: 1.242 s sparse-revlog-before: 1.135 s sparse-revlog-after: 0.860 s NetBeans: unbundling 1K revisions no-sparse-revlog: 1.386 s sparse-revlog-before: 2.368 s sparse-revlog-after: 1.191 s Mozilla: unbundling 1K revisions no-sparse-revlog: 3.103 s sparse-revlog-before: 3.367 s sparse-revlog-after: 3.093 s

histedit: import chistedit curses UI from hg-experimental I don't tend to like curses interfaces, but this gets enough use at work that it seems like it's worth bringing into core. This is a minimal import from hg-experimental revision 4c7f33bf5f00, in that I've done the smallest amount of code movement and editing in order to import the functionality. .. feature:: `hg histedit` will now present a curses UI if curses is available and `ui.interface` or `ui.interface.histedit` is set to `curses`. Differential Revision: https://phab.mercurial-scm.org/D5146

manifest: perform cheap checks before potentially allocating memory Differential Revision: https://phab.mercurial-scm.org/D5258

manifest: also reject obviously-too-short lines when parsing lines Differential Revision: https://phab.mercurial-scm.org/D5257

manifest: make sure there's a filename before bothering to look for newline There's no valid manifest that would have no characters before the NUL byte on a line, and this fixes some erratic timeouts in the fuzzer. Differential Revision: https://phab.mercurial-scm.org/D5256

revlog: replace PyInt_AS_LONG with a more portable helper function PyInt_AS_LONG disappears on Python, and our previous #define was producing some problems on Python 3. Let's give up and make an inline helper function that makes this more sane. Differential Revision: https://phab.mercurial-scm.org/D5235

help: document weird behavior of uisetup() While refactoring ui.log() API, it was really annoying that uisetup() is actually an extsetup() the phase 1. Let's document that. I'm planning to add another uisetup() which is called per ui instance, though I can't think of a good name for it.

help: merge section about uisetup() and extsetup() They are technically the same callback, called only once per process. The section name "ui setup" is confusing, so shouldn't be used.

help: add internals.extensions topic I think it's better to include the API overview in core as we now have the internals section in our help system. Retrieved from the wiki, and formatted as reST. Several wiki links are removed since they are invalid in the help. The sections about example extension are removed at all as they seemed too verbose. https://www.mercurial-scm.org/wiki/WritingExtensions

commandserver: send raw progress information to message channel This is pretty basic implementation to support GUI progress bar.

commandserver: make getpass() request distinct from normal prompt Otherwise, GUI clients would have to parse the prompt text.

commandserver: attach prompt default and choices to message These attributes are important to provide a GUI prompt to user.

test-commandserver: clean up quoting and location of dbgui extension This helps embedding '$' in the script.

ui: extract helpers to write message with type or label This provides a 'type' attribute to command-server clients, which seems more solid than relying on 'ui.<type>' labels. In future patches, type='progress' will be added to send raw progress information.

commandserver: add experimental option to use separate message channel This is loosely based on the idea of the TortoiseHg's pipeui extension, which attaches ui.label to message text so the command-server client can capture prompt text, for example. https://bitbucket.org/tortoisehg/thg/src/4.7.2/tortoisehg/util/pipeui.py I was thinking that this functionality could be generalized to templating, but changed mind as doing template stuff would be unnecessarily complex. It's merely a status message, a simple serialization option should suffice. Since this slightly changes the command-server protocol, it's gated by a config knob. If the config is enabled, and if it's supported by the server, "message-encoding: <name>" is advertised so the client can stop parsing 'o'/'e' channel data and read encoded messages from the 'm' channel. As we might add new message encodings in future releases, client can specify a list of encoding names in preferred order. This patch includes 'cbor' encoding as example. Perhaps, 'json' should be supported as well.