webcommands: document "filediff" web command

webcommands: document "summary" web command

webcommands: document "manifest" web command

webcommands: document "changelog" web command

webcommands: document "file" web command

webcommands: document "log" web command

webcommands: document "shortlog" web command

webcommands: document "changeset" web command

webcommands: document "tags" web command

webcommands: document "bookmarks" web command

webcommands: document "branches" web command

webcommands: document "help" web command

help: add web commands to help documentation The capabilities and URL endpoints of the hgweb server can currently only be inferred by looking at links in `hg serve` output or by reading the source code. I've frequently found myself wanting to quickly see what URLs and capabilities are available. This patch teaches the help system how to display information about web commands and their URLs. Using a mechanism similar to revsets, templates, etc, we can now iterate over the docstrings of registered web command functions and display them in the help output. Unfortunately, web commands don't currently have docstrings, so the output is currently empty. This will be addressed in the following patches. I apologize for the patch bomb.

help.hgweb: add a section describing URLs and common parameters The behavior of hgweb's URLs isn't documented anywhere inside Mercurial. Let's start to change that.

webcommands: move help import into help command handler A subsequent patch will introduce an import cycle between mercurial.help and mercurial.hgweb.webcommands. Break the cycle by moving the import of mercurial.help into the web command that actually needs it.

webcommands: define a dict of available commands This will be used to hook web commands up to the help system. It also makes web commands work similarly as CLI commands.

webcommands: define web commands using a decorator Other parts of Mercurial have evolved to use decorators to declare commands or handlers. This patch gives the same treatment to web commands.

run-tests: ensure install directories exist As part of the transition to setuptools, it was discovered that setuptools doesn't create install directories for you where distutils apparently did. This was causing run-tests.py to fail when creating the temporary hg install. We work around this problem by creating the install directories before running setup.py.

run-tests: avoid printing extra newlines from install log If an installation error occurs, we print the install log. Before, output had extra newlines because we were using "print" on data that was already newline terminated.

bundlerepo: basic bundle2 support For bundlerepo to work with bundle2 files, we need to find the part that contains the bundle's changegroup data and work with that instead of the entire bundle. Future work can add separate processing for other bundle2 parts.

bundlerepo: keep track of the original bundle object Bundlerepo should always close() the object that it receives from exchange.readbundle(). When bundle2 support is added in a later diff, self.bundle will be overwritten to be the changegroup part instead of the entire bundle unpacker.

bundle2.unbundle20: add compressed() method Bundlerepo uses the compressed() method to determine whether it should write an uncompressed temporary file. Since we don't support compressed bundle2 files at the moment, make this method return true.

bundle2.unpackermixin: default value for seek() whence parameter The contract for seek() includes seeking to an offset from the beginning of the file when whence is omitted; put this implementation in compliance.

windows: adjust doc string and comments of posixfile() The doc string of osutil.posixfile includes (line 611): "On error, this function may raise either a WindowsError or an IOError." which is most likely correct, but does not fit for this function here anymore, as we do fold WindowsError to IOError here specifically. And this function is now a bit more than just an exception-wrapper, as it has been expanded to additionally sanitize the unloved seek/tell behavior of Windows. (Self-disclosure: This patch is entirely untested at the time of its publication, as I'm currently not using this version myself. I send it in hopes that it will reduce potential future confusion. CC-ing Matt Harbison)

color: support a different color mode when the pager is active MSYS on Windows has a terminal that supports the "win32" color mode (which "auto" properly detects for us). However, a popularily configured pager in that environment (GNU less) only supports the "ansi" color mode. This patch teaches color about a new config option: pagermode. It behaves like "mode" but is only consulted when the pager is active for the current command. MSYS users can now set "pagermode = ansi" and get a colorful experience that just works. Previously, MSYS users would have to live without color when using GNU less as the pager, would have to manually configure the pager to attend every command, or would have gibberish if "ansi" was used without the pager.

pager: ensure wrapped dispatch._runcommand runs before color's An upcoming patch will teach color to potentially act differently if the pager is active. Since both extensions wrap the same function (dispatch._runcommand) to change behavior, we must guarantee that pager's wrapped function runs before color's so color may read the breadcrumb left by pager.

pager: set an attribute on ui indicating that a pager is active A subsequent patch will teach the color extension to do different things depending on whether a pager is active. This patch leaves a breadcrumb on the ui instance to allow it do that that.

extensions: support callbacks after another extension loads An upcoming patch will introduce a dependency between the color and pager extensions. To prepare for this, we teach extensions how to register callbacks that can execute when another extension loads. This patch is based on code provided by Matt Mackall. But significant parts have changed (such as the ability to register multiple callbacks and the change in behavior to always call a callback). I believe that always firing the callback is a good practice. I think the common use for this feature will be for extensions to say "run this one-time setup code, after this other extension if possible." Always running the callback will facilitate this.

log: fix --follow null parent not to include revision 0 If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null, only revision 0 was visible. Because 'null' should not be listed implicitly, "log --follow" (without -r) should be empty if p1 is null. Test of "hg grep -f" is added for cmdutil.walkchangerevs().

cmdutil: have walkchangerevs utilize common function to build revs