bundle2: disable ouput capture unless we use http (issue4613 issue4615) The current bundle2 processing was capturing all output. This is nice as it provide better meta data about what output what, but this was changing two things: 1) adding a prefix "remote: " to "other" output during local push (issue4613) 2) local and ssh push does not provide real time output anymore (issue4615) As we are unsure about what form should be used in (1) and how to solve (2) we disable output capture in this two cases. Output capture can be forced using an experimental option.

subrepo: propagate the --hidden option to hg subrepositories With many commands accepting a '-S' or an explicit path to trigger recursing into subrepos, it seems that --hidden needs to be propagated too. Unfortunately, many of the subrepo layer methods discard the options map, so passing the option along explicitly isn't currently an option. It also isn't clear if other filtered views need to be propagated, so changing all of those commands may be insufficient anyway. The specific jam I got into was amending an ancestor of qbase in a subrepo, and then evolving. The patch ended up being hidden, and outgoing said it would only push one unrelated commit. But push aborted with an 'unknown revision' that I traced back to the patch. (Odd it didn't say 'filtered revision'.) A push with --hidden worked from the subrepo, but that wasn't possible from the parent repo before this. Since the underlying problem doesn't actually require a subrepo, there's probably more to investigate here in the discovery area. Yes, evolve + mq is not exactly sane, but I don't know what is seeing the hidden revision. In lieu of creating a test for the above situation (evolving mq should probably be blocked), the test here is a marginally useful case where --hidden is needed in a subrepo: cat'ing a file in a hidden revision. Without this change, cat aborts with: $ hg --hidden cat subrepo/a skipping missing subrepository: subrepo [1]

subrepo: don't pass the outer repo's --rev or --branch to subrepo incoming() When passing a --rev, 'hg incoming -S' previously suffered from the same output truncation or abort that was fixed for 'hg outgoing -S' in the previous patch, for the same reasons. Unlike push, subrepos are currently only pulled when the outer repo is updated, not when the outer repo is pulled. That makes matching 'hg pull' behavior impossible. Listing all incoming csets in the subrepo seems like the most useful behavior, and is consistent with 'hg outgoing -S'.

subrepo: don't pass the outer repo's --rev or --branch to subrepo outgoing() The previous behavior didn't reflect what would actually be pushed- push will ignore --rev and --branch in the subrepo and push everything. Therefore, 'push -r {rev}' would not list everything, unless {rev} was also the revision of the subrepo's tip. Worse, if a hash was passed in, the command would abort because that hash would either not be in the outer repo or not in the subrepo.

subrepo: update the help text to account for diff -I/-X gitsubrepo support The functionality was added in a48b65ab428d.

revert: make the interactive mode experimental While fixing issue4304: "record: allow editing new files" we introduced changes in record/crecord. These changes need to be matched with changes in any command using record. Revert is one of these commands and the changes have not been made for this release. Therefore, revert -i should be an experimental feature for this release.

shelve: make the interactive mode experimental While fixing issue4304: "record: allow editing new files" we introduced changes in record/crecord. These changes need to be matched with changes in any command using record. Shelve is one of these commands and the changes have not been made for this release. Therefore, shelve -i should be an experimental feature for this release.

help: also hide options marked EXPERIMENTAL Similar to DEPRECATED, add a way to indicate that options are EXPERIMENTAL.

rebase: don't forward "source" argument to rebase (issue4633) `hg pull` takes an optional "source" argument to define the path/url to pull from. Under some circumstances, this option could get proxied to rebase and interpretted as the --source argument to rebase, leading to unexpected behavior. In my local environment, "source" always appears in "opts" in pullrebase. However, when attempting to write a test, I couldn't reproduce this. Instead, the source is being captured as a positional argument in "args." I suspect an interaction between **kwargs and an extension is to blame for the differences in behavior. This is why no test has been written. I have tested behavior locally and the patch has the intended side-effect of making `hg pull --rebase` work again.

histedit: fix reST syntax problem of example code in help document To show example code correctly in online help, text block of it should be preceded by "::" and indented.

webcommands: fix description of manifest default behavior

webcommands: fix typo in changelog documentation

record: fix adding new file with record from within a subdir (issue4626) In my latest change on record (edit newly added file), I forgot the repo.wjoin() so that record was not computing the paths properly to delete the backups and was crashing.

tests: fix backslashes in test-casefolding

cmdutil: avoid wrapping ctx.phasestr() by _() This wrapping seems meaningless, because: - there is no "_()" invocation to prepare for extracting phase names to be translated "make update-pot" doesn't extract msgids for phase names - phase names are kine of reserved keywords like as branch name "default"

repair: avoid string concatenation by + operator String concatenation by "+" operator causes failure of extracting messages to be translated. Python automatically concatenates strings separated by whitespaces into one string.

annotate: always adjust linkrev before walking down to parents (issue4623) This should avoid the bad performance in the following scenario. Before this patch, on "hg annotate -r10000", p.rev() would walk changelog from 10000 to 3 because _descendantrev was 10000. With this patch, it walks from 5 to 3. 1 -- 2 -- 4 -- 5 -- ... -- 10000 \ 'p' 'f' - 3 (grafted 3 to 4) 'p' repo: https://hg.mozilla.org/releases/mozilla-beta/#4f80fecda802 command: hg annotate -r b0a57152fd14 browser/app/profile/firefox.js before: 83.120 secs after: 3.820 secs This patch involves extra calls of narrow _adjustlinkrev(), but the cost of them seems relatively small compared to wide _adjustlinkrev() calls eliminated by this patch. repo: http://selenic.com/repo/hg/#8015a3cf1380 command: hg annotate mercurial/commands.py before: 7.380 secs after: 7.320 secs repo: https://hg.mozilla.org/mozilla-central/#f214df6ac75f command: hg annotate layout/generic/nsTextFrame.cpp before: 5.070 secs after: 5.050 secs repo: https://hg.mozilla.org/releases/mozilla-beta/#4f80fecda802 command: hg annotate -r 4954faa47dd0 gfx/thebes/gfxWindowsPlatform.cpp before: 1.600 secs after: 1.620 secs

test-commit-interactive: stablize output for no-execbit platforms

test-bundle2-exchange: make hooks compatible with Windows The cmd.exe process doesn't fail the hook when "; false" is appended, and its echo command prints out the quote characters.

i18n: extract doc string of each web commands as translatable one Before this patch, doc string of each web commands isn't extracted as translatable one, even though web commands are listed up in "hg help hgweb". This patch adds "mercurial/hgweb/webcommands.py" on to arguments of "i18n/hggettext". "i18nfunctions" added into "webcommands.py" is used by "i18n/hggettext" to get the list of functions having translatable doc string.

subrepo: don't write .hgsubstate lines with empty subrepo state (issue4622) The '' that is used to represent the state of a not-yet-committed subrepo cannot be written to the file, because the code that parses the file splits on ' ' and expects two parts. Given that the .hgsubstate file is automatically rewritten on commit, it seems a little strange that the file is written out during a merge.

revert: restore the ability to revert across case only renames (issue4481) This regressed in 5e16fe6fdd32, in what looks like an unrelated change. It seems sufficient to pass 'ignoremissing=True', but the restored try/except has been there for six years since 41bb88cb913e, so this seems safer for now. Note that renaming directories in the filename doesn't appear to work- not sure if this would end up throwing a different type of error when that is fixed.

convert: avoid traceback in subversion sink We've had a couple reports of subversion tracebacks that trigger when the parents list is empty, and thus block showing what the commit failure was on the next two lines.

merge with i18n