smartset: preserve istopo for baseset operations This is a follow-up of "smartset: use native set operations as fast paths". It's more correct to just preserve the "istopo" information for "&" and "-" operations, like what filteredset does.

record: update help to describe ui.interface hg help record was not accurate if using another interface than the text one

ui: replace obsolete default-push with default:pushurl (issue5485) Default-push has been deprecated in favour of default:pushurl. But "hg clone" still inserts this in every hgrc file it creates. This patch updates the message by replacing default-push with default:pushurl and also makes the necessary changes to test files.

worker: ignore meaningless exit status indication returned by os.waitpid() Before this patch, worker implementation assumes that os.waitpid() with os.WNOHANG returns '(0, 0)' for still running child process. This is explicitly specified as below in Python API document. os.WNOHANG The option for waitpid() to return immediately if no child process status is available immediately. The function returns (0, 0) in this case. On the other hand, POSIX specification doesn't define the "stat_loc" value returned by waitpid() with WNOHANG for such child process. http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitpid.html CPython implementation for os.waitpid() on POSIX doesn't take any care of this gap, and this may cause unexpected "exit status indication" even on POSIX conformance platform. For example, os.waitpid() with os.WNOHANG returns non-zero "exit status indication" on FreeBSD. This implies os.kill() with own pid or sys.exit() with non-zero exit code, even if no child process fails. To ignore meaningless exit status indication returned by os.waitpid(), this patch skips subsequent steps forcibly, if os.waitpid() returns 0 as pid. This patch also arranges examination of 'p' value for readability. FYI, there are some issues below about this behavior reported for CPython. https://bugs.python.org/issue21791 https://bugs.python.org/issue27808

pager: add a config knob to just globally turn off the pager

pager: move most help to a new help topic and deprecate extension

dispatch: rearrange 'unknown command' code to better employ pager dispatch calls help like a ninja if you give it a truly unknown command, and that might want to be paged. If it gets paged, then the 'hg: unknown command' text gets eaten by a grue, unless we call the pager first. This change rearranges the codepaths so we can safely only invoke the pager in the case where we'll have long output from the help command code, rather than just a short message like "did you mean stat instead of start" or "fetch is provided by the fetch extension".

help: move rst formatting of help documents into help.py This slight refactor will help me improve the 'unknown command' experience in our new glorious pager future.

outgoing: avoid running pager until we're actually showing changes Consistent with the new behavior of incoming in the previous patch.

incoming: delay pager activation until right before printing changes This prevents authentication and other brief status messages from being paged.

histedit: modify rollup to discard date from the rollup commit (issue4820) This change adjusts and documents the new behaviour of 'roll'. It now fits nicely with the behaviour of 'commit --amend' and the 'edit' action, by discarding the date as well as the commit message of the second commit. Previously it used the later date, like 'fold', but this often wasn't desirable, for example, in the common use case of using 'roll' to add forgotten changes to a changeset (because 'hg add' was previously forgotten or not all changes were identified while using 'hg record').

histedit: improve documentation and behaviour of dates This clarifies in the histedit documentation that the 'edit' action preserves the date and that the 'fold' action uses the later date. The documentation was previously silent on this issue which left users in doubt.

localrepo: check HG_PENDING strictly Before this patch, checking HG_PENDING for changelog in localrepo.py might cause unintentional reading unrelated '00changelog.i.a' in, because HG_PENDING is checked by str.startswith(). An external hook spawned by inner repository in nested ones satisfies this condition. This patch uses txnutil.mayhavepending() to check HG_PENDING strictly. BTW, this patch may cause failure of bisect in the repository of Mercurial itself, if examination at bisecting assumes that an external hook can see all pending changes while nested transactions across repositories. This invisibility issue will be fixed by subsequent patch, which allows HG_PENDING to refer multiple repositories.

phases: check HG_PENDING strictly Before this patch, checking HG_PENDING in phases.py might cause unintentional reading unrelated 'phaseroots.pending' in, because it just examines existence of HG_PENDING environment variable. This patch uses txnutil.trypending() to check HG_PENDING strictly. BTW, this patch may cause failure of bisect in the repository of Mercurial itself, if examination at bisecting assumes that an external hook can see all pending changes while nested transactions across repositories. This invisibility issue will be fixed by subsequent patch, which allows HG_PENDING to refer multiple repositories.

bookmarks: check HG_PENDING strictly Before this patch, checking HG_PENDING in bookmarks.py might cause unintentional reading unrelated '.hg/bookmarks.pending' in, because it just examines existence of HG_PENDING environment variable. This patch uses txnutil.trypending() to check HG_PENDING strictly. This patch also changes share extension. Enabling share extension (+ bookmark sharing) makes bookmarks._getbkfile() receive repo to be shared (= "srcrepo"). On the other hand, HG_PENDING always refers current working repo (= "currepo"), and bookmarks.pending is written only into currepo. Therefore, we should try to read .hg/bookmarks.pending of currepo in at first. If it doesn't exist, we try to read .hg/bookmarks of srcrepo in. Even after this patch, an external hook spawned in currepo can't see pending changes in currepo via srcrepo, even though such changes become visible after closing transaction, because there is no easy and cheap way to know existence of pending changes in currepo via srcrepo. Please see https://www.mercurial-scm.org/wiki/SharedRepository, too. BTW, this patch may cause failure of bisect in the repository of Mercurial itself, if examination at bisecting assumes that an external hook can see all pending changes while nested transactions across repositories. This invisibility issue will be fixed by subsequent patch, which allows HG_PENDING to refer multiple repositories.

tests: make directory to prevent test process from going out of $TESTTMP Before this patch, test process for test-bookmarks.t goes out of $TESTTMP at "cd .." before creation of "orderrepo" repository. To prevent test process from going out of $TESTTMP, this patch makes directory "repo" sub-directory and executes almost all test scenarios in test-bookmarks.t under it. This is preparation for new test added in subsequent patch.

txnutil: factor out the logic to read file in according to HG_PENDING This patch adds new file txnutil.py, because: - transaction.py is too large to import small utility logic - scmutil.py or so causes cyclic importing in phases.py mayhavepending() is defined separately for convenience in subsequent patch.

repoview: separate cache hash computation from cache reading This change will make it easier for extensions to use another cache hash.

tests: make test suite more immune to environment variables Plenty of tests break when "make tests" is run while environment variables "HGPLAIN" or "HGPLAINEXCEPT" are set (test "test-obsolete- checkheads.t" is just a single example). This patch causes script "run-tests.py" to also remove these two variables from the environment the tests are executed in.

version: enable pager if --verbose is specified `hg version` output is very short without --verbose, but with --verbose it tends to scroll off the user's screen.

tags: enable pager

summary: enable pager

status: enable pager

resolve: enable pager

paths: enable pager

outgoing: enable pager The structure here is similar to incoming, and requires similar treatment.

manifest: enable pager

locate: enable pager

incoming: enable pager The design of incoming means we have to activate the pager in several places, depending on which codepath gets chosen.

help: enable pager

grep: enable pager

files: enable pager