minirst: remove "admonition" from _admonitions The "admonition" rst primitive is split into "specific" admonitions ("attention," "caution," etc) and the "generic" admonition ("admonition"). For more, see http://docutils.sourceforge.net/docs/ref/rst/directives.html#admonitions The _admonitions set and keys of the _admonitiontitles dict overlap exactly except _admonitions has an "admonition" entry. Nowhere in Mercurial is the "admonition" admonition directive used. Even if it were, it doesn't have a title, so it wouldn't be rendered correctly. So, let's remove "admonition" from the set of recognized admonition directives.

minirst: reindent _admonitiontitles I don't like the verical indent. While I was here, I cleaned up some whitespace and added a trailing comma on the last element.

tags: extract filenode filtering into its own function We'll also need to reuse this logic so we extract it into its own function. We document some of the logic in the process.

tags: extract tags computation from fnodes into its own function I'm about to introduce code that needs to perform such computation on "arbitrary" nodes. The logic is extracted into its own function for reuse.

tags: only return 'alltags' in 'findglobaltags' This is minor update along the way. We simplify the 'findglobaltags' function to only return the tags. Since no existing data is reused, we know that all tags returned are global and we can let the caller get that information if it cares about it.

tags: make argument 'tagtype' optional in '_updatetags' This is the next step from the previous changesets, we are now ready to use this function in a simpler way.

tags: reorder argument of '_updatetags' We move all arguments related to tagtype to the end, together. This will allow us to make these arguments optional and reuse of this logic for callers that do not care about the tag types.

tags: do not feed dictionaries to 'findglobaltags' The code asserts that these dictionary are empty. So we can be more explicit and have the function return the dictionaries directly.

tags: extract fnode retrieval into its own function My main goal here is to be able to reuse this logic easily. As a side effect this important logic is now insulated and the code is clearer.

hgweb: fix diff hunks filtering by line range in webutil.diffs() The previous clause for filter out a diff hunk was too restrictive. We need to consider the following cases (assuming linerange=(lb, ub) and the @s2,l2 hunkrange): <-(s2)--------(s2+l2)-> <-(lb)---(ub)-> <-(lb)---(ub)-> <-(lb)---(ub)-> previously on the first and last situations were considered. In test-hgweb-filelog.t, add a couple of lines at the beginning of file "b" so that the line range we will follow does not start at the beginning of file. This covers the change in aforementioned diff hunk filter clause.

summary: display obsolete state of parents Extend the "parent: " lines in summary to display "(obsolete)" when the parent is obsolete.

templates: add "changeset.obsolete" label in command line style Following respective change in cmdutil.changeset_printer.

templates: shorten definition of changeset labels in command-line style We'll add more labels and the line is already quite long, so let's define a variable to hold all evolution "troubles" labels.

templates: use separate() to build changeset labels in command-line style

templatekw: add an "obsolete" keyword Definition is the same as the one in evolve extension.

cmdutil: add a "changeset.obsolete" label in changeset_printer Until now there were no label to highlight obsolete changesets in log output, only evolution troubles (unstable, bumped, divergent) are supported. We add a "changeset.obsolete" label on changeset entries produced by changeset_printer so that obsolete changesets can be highlighted in log output. This is useful because, unless using a graph log where obsolete changesets have a 'x' marker, there's no way to identify obsolete changesets. And even in graph mode, when working directory's parent is obsolete, we get a '@' marker and we do not see it as obsolete.

fileset: perform membership test against set for status queries Previously, fileset functions operating on status items performed membership tests against a list of items. When there are thousands of items having a specific status, that test can be extremely slow. Changing the membership test to a set makes this operation substantially faster. On the mozilla-central repo: $ hg files -r d14cac631ecc 'set:added()' before: 28.120s after: 0.860s $ hg status --change d14cac631ecc --added 0.690s

worker: flush ui buffers before running the worker a91c6275 introduces flushing ui buffers after a worker finished. If the ui was not flushed before the worker was started, fork will copy the existing buffers to the worker. This causes messages issued before the worker started to be written to the terminal for each worker. We are now flushing the ui before we start a worker and add an appropriate test which will fail before this patch.

chgserver: do not copy configs set by environment variables Config set by environment variables have a source like "$ENVNAME". They should not be copied because they will be recalculated by rcutil.rccomponents.

rcutil: extract duplicated logic to a lambda This simplifies the code a bit.

rcutil: unindent a block Since global _rccomponents is gone, the code could be simplified.

rcutil: do not cache rccomponents The function is only called once except for "hg debugconfig", where it is called twice. So there is no need to cache it. Caching it will cause issues with chgserver. Instead of dropping the cache in chgserver, it seems cleaner to just avoid the cache.

ui: rerun color.setup() once the pager has spawned to honor 'color.pagermode' Otherwise, ui.pageractive is False when color is setup in dispatch.py (without --pager=on), and this config option is ignored.

ui: defer setting pager related properties until the pager has spawned When --pager=on is given, dispatch.py spawns a pager before setting up color. If the pager failed to launch, ui.pageractive was left set to True, so color configured itself based on 'color.pagermode'. A typical MSYS setting would be 'color.mode=auto, color.pagermode=ansi'. In the failure case, this would print a warning, disable the pager, and then print the raw ANSI codes to the terminal. Care needs to be taken, because it appears that leaving ui.pageractive=True was the only thing that prevented an attempt at running the pager again from inside the command. This results in a double warning message, so pager is simply disabled on failure. The ui config settings didn't need to be moved to fix this, but it seemed like the right thing to do for consistency.