progress: move all logic altering the ui object logic in mercurial.ui The ui object can take care of its progress object logic by itself. test-subrepo-recursion is modified because it is a bit sensitive to the "no progress bar" default. It will become unnecessary in the next step when progress will be on by default in core.

progress: move the singleton logic to the ui module The use of a singleton for all of progress handling is debatable (because config may vary). However this is how the extension has been doing it so far. We move that code into the ui module because this is where is should belong when progress is moved into core.

progress: move most extension code into a 'mercurial.progress' module This initiate the relocation of progress into core.

test-subrepo-recursion: restore globs for Windows

tests: restore 'python' and '$TESTDIR/' for dummyssh invocation This is a backout of 46727fea7a00, and a partial backout of c3ecbf694904. Windows won't execute 'dummyssh' directly, presumably because CreateProcess() doesn't know how to execute a bash script: $ hg clone -e "dummyssh" ssh://user@dummy/cloned sshclone remote: 'dummyssh' is not recognized as an internal or external command, remote: operable program or batch file. abort: no suitable response from remote hg! [255] With the restoration of python as the executable, $TESTDIR needs to be restored for these invocations, because python won't search $PATH for 'dummyssh': $ hg clone -e "python dummyssh" ssh://user@dummy/cloned sshclone remote: python: can't open file 'dummyssh': [Errno 2] No such file or directory abort: no suitable response from remote hg! [255]

perf: support -T for every perf commands We are already building a formatter, we can now pass it options the official way.

bundle2: convey PushkeyFailed error over the wire We add a way to convey the precise exception. This will allow better error message on the server.

bundle2: also capture reply capability on failure When unbundling over the wire is aborted, we have a mechanism to convey the error inside a bundle part. As we add support for more errors, we need to know if the client will support them. For this purpose, we duck punch the reply capabilities of the client on the raised extensions. This is similar to what is done to salvage the server output on error.

bundle2: add an 'error' capability This capability will be extended as new error type is introduced.

merge with stable