neulab/tldr huggingface dataset:
The supported glob syntax extensions are ** to match any string across path separators and {a,b} to mean "a or b".
To use a Perl/Python regular expression, start a name with re:.  Regexp pattern matching is anchored at the root of the repository.
To read name patterns from a file, use listfile: or listfile0:.  The latter expects null delimited patterns while the former expects line feeds. Each string read from the file is itself treated as a file pattern.
To read a set of patterns from a file, use include: or subinclude:. include: will use all the patterns from the given file and treat them as if they had been passed in manually.  subinclude: will only apply the patterns against files that are under the subinclude file's directory. See hg help hgignore for details on the format of these files.
All patterns, except for glob: specified in command line (not for -I or -X options), can match also against directories: files under matched directories are treated as matched.  For -I and -X options, glob: will match directories recursively.
Plain examples:
path:foo/bar        a name bar in a directory named foo in the root of the repository path:path:name      a file or directory named "path:name" rootfilesin:foo/bar the files in a directory called foo/bar, but not any files in its subdirectories and not a file bar in directory foo
Glob examples:
glob:*.c       any name ending in ".c" in the current directory *.c            any name ending in ".c" in the current directory **.c           any name ending in ".c" in any subdirectory of the current directory including itself. foo/*          any file in directory foo foo/**         any file in directory foo plus all its subdirectories, recursively foo/*.c        any name ending in ".c" in the directory foo foo/**.c       any name ending in ".c" in any subdirectory of foo including itself. rootglob:*.c   any name ending in ".c" in the root of the repository
Regexp examples:
re:.*\.c$      any name ending in ".c", anywhere in the repository
File examples:
listfile:list.txt  read list from list.txt with one file pattern per line listfile0:list.txt read list from list.txt with null byte delimiters
See also hg help filesets.
Include examples:
include:path/to/mypatternfile    reads patterns to be applied to all paths subinclude:path/to/subignorefile reads patterns specifically for paths in the subdirectory
What are phases? Phases are a system for tracking which changesets have been or should be shared. This helps prevent common mistakes when modifying history (for instance, with the mq or rebase extensions).
Each changeset in a repository is in one of the following phases:
• public : changeset is visible on a public server
• draft : changeset is not yet published
• secret : changeset should not be pushed, pulled, or cloned
These phases are ordered (public < draft < secret) and no changeset can be in a lower phase than its ancestors. For instance, if a changeset is public, all its ancestors are also public. Lastly, changeset phases should only be changed towards the public phase.
How are phases managed? For the most part, phases should work transparently. By default, a changeset is created in the draft phase and is moved into the public phase when it is pushed to another repository.
Once changesets become public, extensions like mq and rebase will refuse to operate on them to prevent creating duplicate changesets.  Phases can also be manually manipulated with the hg phase command if needed. See hg help -v phase for examples.
To make your commits secret by default, put this in your configuration file:
[phases] new-commit = secret
Phases and servers Normally, all servers are publishing by default. This means:
- all draft changesets that are pulled or cloned appear in phase public on the client
- all draft changesets that are pushed appear as public on both client and server
- secret changesets are neither pushed, pulled, or cloned
Note   Pulling a draft changeset from a publishing server does not mark it as public on the server side due to the read-only nature of pull.
Sometimes it may be desirable to push and pull changesets in the draft phase to share unfinished work. This can be done by setting a repository to disable publishing in its configuration file:
[phases] publish = False
Note   Servers running older versions of Mercurial are treated as publishing.
Note   Changesets in secret phase are not exchanged with the server. This applies to their content: file names, file contents, and changeset metadata. For technical reasons, the identifier (e.g. d825e4025e39) of the secret changeset may be communicated to the server.
Examples • list changesets in draft or secret phase:
hg log -r "not public()"
• change all secret changesets to draft:
hg phase --draft "secret()"
• forcibly move the current changeset and descendants from public to draft:
hg phase --force --draft .
• show a list of changeset revisions and each corresponding phase:
hg log --template "{rev} {phase}\n"
• resynchronize draft changesets relative to a remote repository:
hg phase -fd "outgoing(URL)"
See hg help phase for more information on manually manipulating phases.
Mercurial supports several ways to specify revisions.
Specifying single revisions A plain integer is treated as a revision number. Negative integers are treated as sequential offsets from the tip, with -1 denoting the tip, -2 denoting the revision prior to the tip, and so forth.
A 40-digit hexadecimal string is treated as a unique revision identifier. A hexadecimal string less than 40 characters long is treated as a unique revision identifier and is referred to as a short-form identifier. A short-form identifier is only valid if it is the prefix of exactly one full-length identifier.
Any other string is treated as a bookmark, tag, or branch name. A bookmark is a movable pointer to a revision. A tag is a permanent name associated with a revision. A branch name denotes the tipmost open branch head of that branch - or if they are all closed, the tipmost closed head of the branch. Bookmark, tag, and branch names must not contain the ":" character.
The reserved name "tip" always identifies the most recent revision.
The reserved name "null" indicates the null revision. This is the revision of an empty repository, and the parent of revision 0.
The reserved name "." indicates the working directory parent. If no working directory is checked out, it is equivalent to null. If an uncommitted merge is in progress, "." is the revision of the first parent.
Finally, commands that expect a single revision (like hg update) also accept revsets (see below for details). When given a revset, they use the last revision of the revset. A few commands accept two single revisions (like hg diff). When given a revset, they use the first and the last revisions of the revset.
Specifying multiple revisions Mercurial supports a functional language for selecting a set of revisions. Expressions in this language are called revsets.
The language supports a number of predicates which are joined by infix operators. Parenthesis can be used for grouping.
Identifiers such as branch names may need quoting with single or double quotes if they contain characters like - or if they match one of the predefined predicates.
Changesets not in x. Short form is ! x.
x::y
A DAG range, meaning all changesets that are descendants of x and ancestors of y, including x and y themselves. If the first endpoint is left out, this is equivalent to ancestors(y), if the second is left out it is equivalent to descendants(x).
An alternative syntax is x..y.
x:y
All changesets with revision numbers between x and y, both inclusive. Either endpoint can be left out, they default to 0 and tip.
The intersection of changesets in x and y. Short form is x & y.
The union of changesets in x and y. There are two alternative short forms: x | y and x + y.
Changesets in x but not in y.
x % y
Changesets that are ancestors of x but not ancestors of y (i.e. ::x - ::y).  This is shorthand notation for only(x, y) (see below). The second argument is optional and, if left out, is equivalent to only(x).
x^n
The nth parent of x, n == 0, 1, or 2.  For n == 0, x; for n == 1, the first parent of each changeset in x; for n == 2, the second parent of changeset in x.
x~n
The nth first ancestor of x; x~0 is x; x~3 is x^^^.  For n < 0, the nth unambiguous descendent of x.
x ## y
Concatenate strings and identifiers into one string.
All other prefix, infix and postfix operators have lower priority than ##. For example, a1 ## a2~2 is equivalent to (a1 ## a2)~2.
[revsetalias] issue(a1) = grep(r'\bissue[ :]?' ## a1 ## r'\b|\bbug\(' ## a1 ## r'\)')
issue(1234) is equivalent to grep(r'\bissue[ :]?1234\b|\bbug\(1234\)') in this case. This matches against all of "issue 1234", "issue:1234", "issue1234" and "bug(1234)".
There is a single postfix operator:
Equivalent to x^1, the first parent of each changeset in x.
Patterns Where noted, predicates that perform string matching can accept a pattern string. The pattern may be either a literal, or a regular expression. If the pattern starts with re:, the remainder of the pattern is treated as a regular expression. Otherwise, it is treated as a literal. To match a pattern that actually starts with re:, use the prefix literal:.
Matching is case-sensitive, unless otherwise noted.  To perform a case- insensitive match on a case-sensitive predicate, use a regular expression, prefixed with (?i).
For example, tag(r're:(?i)release') matches "release" or "RELEASE" or "Release", etc.
adds(pattern)
Changesets that add a file matching pattern.
The pattern without explicit kind like glob: is expected to be relative to the current directory and match against a file or a directory.
All changesets, the same as 0:tip.
ancestor(*changeset)
A greatest common ancestor of the changesets.
Accepts 0 or more changesets.  Will return empty list when passed no args.  Greatest common ancestor of a single changeset is that changeset.
ancestors(set[, depth])
Changesets that are ancestors of changesets in set, including the given changesets themselves.
If depth is specified, the result only includes changesets up to the specified generation.
author(string)
Alias for user(string).
bisect(string)
Changesets marked in the specified bisect status:
• good, bad, skip: csets explicitly marked as good/bad/skip
• goods, bads      : csets topologically good/bad
• range              : csets taking part in the bisection
• pruned             : csets that are goods, bads or skipped
• untested           : csets whose fate is yet unknown
• ignored            : csets ignored due to DAG topology
• current            : the cset currently being bisected
bookmark([name])
The named bookmark or all bookmarks.
Pattern matching is supported for name. See hg help revisions.patterns.
branch(string or set)
All changesets belonging to the given branch or the branches of the given changesets.
Pattern matching is supported for string. See hg help revisions.patterns.
branchpoint()
Changesets with more than one child.
bundle()
Changesets in the bundle.
Bundle must be specified by the -R option.
children(set)
Child changesets of changesets in set.
closed()
Changeset is closed.
commonancestors(set)
Changesets that are ancestors of every changeset in set.
conflictlocal()
The local side of the merge, if currently in an unresolved merge.
"merge" here includes merge conflicts from e.g. 'hg rebase' or 'hg graft'.
conflictother()
The other side of the merge, if currently in an unresolved merge.
contains(pattern)
The revision's manifest contains a file matching pattern (but might not modify it). See hg help patterns for information about file patterns.
The pattern without explicit kind like glob: is expected to be relative to the current directory and match against a file exactly for efficiency.
converted([id])
Changesets converted from the given identifier in the old repository if present, or all converted changesets if no identifier is specified.
date(interval)
Changesets within the interval, see hg help dates.
desc(string)
Search commit message for string. The match is case-insensitive.
descendants(set[, depth])
Changesets which are descendants of changesets in set, including the given changesets themselves.
destination([set])
Changesets that were created by a graft, transplant or rebase operation, with the given revisions specified as the source. Omitting the optional set is the same as passing all().
diffcontains(pattern)
Search revision differences for when the pattern was added or removed.
The pattern may be a substring literal or a regular expression. See hg help revisions.patterns.
draft()
Changeset in draft phase.
expectsize(set[, size])
Return the given revset if size matches the revset size.  Abort if the revset doesn't expect given size.  size can either be an integer range or an integer.
For example, expectsize(0:1, 3:5) will abort as revset size is 2 and 2 is not between 3 and 5 inclusive.
extra(label, [value])
Changesets with the given label in the extra metadata, with the given optional value.
Pattern matching is supported for value. See hg help revisions.patterns.
file(pattern)
Changesets affecting files matched by pattern.
For a faster but less accurate result, consider using filelog() instead.
This predicate uses glob: as the default kind of pattern.
filelog(pattern)
Changesets connected to the specified filelog.
For performance reasons, visits only revisions mentioned in the file-level filelog, rather than filtering through all changesets (much faster, but doesn't include deletes or duplicate changes). For a slower, more accurate result, use file().
first(set, [n])
An alias for limit().
follow([file[, startrev]])
An alias for ::. (ancestors of the working directory's first parent).  If file pattern is specified, the histories of files matching given pattern in the revision given by startrev are followed, including copies.
followlines(file, fromline:toline[, startrev=., descend=False])
Changesets modifying file in line range ('fromline', 'toline').
Line range corresponds to 'file' content at 'startrev' and should hence be consistent with file size. If startrev is not specified, working directory's parent is used.
By default, ancestors of 'startrev' are returned. If 'descend' is True, descendants of 'startrev' are returned though renames are (currently) not followed in this direction.
Like keyword(string) but accepts a regex. Use grep(r'...') to ensure special escape characters are handled correctly. Unlike keyword(string), the match is case-sensitive.
head()
Changeset is a named branch head.
heads(set)
Members of set with no children in set.
hidden()
Hidden changesets.
id(string)
Revision non-ambiguously specified by the given hex string prefix.
keyword(string)
Search commit message, user name, and names of changed files for string. The match is case-insensitive.
For a regular expression or case sensitive search of these fields, use grep(regex).
last(set, [n])
Last n members of set, defaulting to 1.
limit(set[, n[, offset]])
First n members of set, defaulting to 1, starting from offset.
matching(revision [, field])
Changesets in which a given set of fields match the set of fields in the selected revision or set.
To match more than one field pass the list of fields to match separated by spaces (e.g. author description).
Valid fields are most regular revision fields and some special fields.
Regular revision fields are description, author, branch, date, files, phase, parents, substate, user and diff.  Note that author and user are synonyms. diff refers to the contents of the revision. Two revisions matching their diff will also match their files.
Special fields are summary and metadata: summary matches the first line of the description.  metadata is equivalent to matching description user date (i.e. it matches the main metadata fields).
metadata is the default field which is used when no fields are specified. You can match more than one field at a time.
max(set)
Changeset with highest revision number in set.
Changeset is a merge changeset.
min(set)
Changeset with lowest revision number in set.
modifies(pattern)
Changesets modifying files matched by pattern.
named(namespace)
The changesets in a given namespace.
Pattern matching is supported for namespace. See hg help revisions.patterns.
nodefromfile(path)
none()
No changesets.
only(set, [set])
Changesets that are ancestors of the first set that are not ancestors of any other head in the repo. If a second set is specified, the result is ancestors of the first set that are not ancestors of the second set (i.e. ::<set1> - ::<set2>).
origin([set])
Changesets that were specified as a source for the grafts, transplants or rebases that created the given revisions.  Omitting the optional set is the same as passing all().  If a changeset created by these operations is itself specified as a source for one of these operations, only the source changeset for the first operation is selected.
outgoing([path])
Changesets not found in the specified destination repository, or the default push location.
If the location resolve to multiple repositories, the union of all outgoing changeset will be used.
p1([set])
First parent of changesets in set, or the working directory.
p2([set])
Second parent of changesets in set, or the working directory.
parents([set])
The set of all parents for all changesets in set, or the working directory.
present(set)
An empty set, if any revision in set isn't found; otherwise, all revisions in set.
If any of specified revisions is not present in the local repository, the query is normally aborted. But this predicate allows the query to continue even in such cases.
public()
Changeset in public phase.
remote([id [,path]])
Local revision that corresponds to the given identifier in a remote repository, if present. Here, the '.' identifier is a synonym for the current local branch.
removes(pattern)
Changesets which remove files matching pattern.
rev(number)
Revision with the given numeric identifier.
reverse(set)
Reverse order of set.
revset(set)
Strictly interpret the content as a revset.
The content of this special predicate will be strictly interpreted as a revset. For example, revset(id(0)) will be interpreted as "id(0)" without possible ambiguity with a "id(0)" bookmark or tag.
roots(set)
Changesets in set with no parent changeset in set.
secret()
Changeset in secret phase.
sort(set[, [-]key... [, ...]])
Sort set by keys. The default sort order is ascending, specify a key as -key to sort in descending order.
The keys can be:
• rev for the revision number,
• branch for the branch name,
• desc for the commit message (description),
• user for user name (author can be used as an alias),
• date for the commit date
• topo for a reverse topographical sort
• node the nodeid of the revision
The topo sort order cannot be combined with other sort keys. This sort takes one optional argument, topo.firstbranch, which takes a revset that specifies what topographical branches to prioritize in the sort.
Changesets that add, modify or remove the given subrepo.  If no subrepo pattern is named, any subrepo changes are returned.
tag([name])
The specified tag by name, or all tagged revisions if no name is given.
user(string)
User name contains string. The match is case-insensitive.
Aliases New predicates (known as "aliases") can be defined, using any combination of existing predicates or other aliases. An alias definition looks like:
<alias> = <definition>
in the revsetalias section of a Mercurial configuration file. Arguments of the form a1, a2, etc. are substituted from the alias into the definition.
[revsetalias] h = heads() d(s) = sort(s, date) rs(s, k) = reverse(sort(s, k))
defines three aliases, h, d, and rs. rs(0:tip, author) is exactly equivalent to reverse(sort(0:tip, author)).
Equivalents Command line equivalents for hg log:
-f    ->  ::. -d x  ->  date(x) -k x  ->  keyword(x) -m    ->  merge() -u x  ->  user(x) -b x  ->  branch(x) -P x  ->  !::x -l x  ->  limit(expr, x)
• Changesets on the default branch:
hg log -r "branch(default)"
• Changesets on the default branch since tag 1.5 (excluding merges):
hg log -r "branch(default) and 1.5:: and not merge()"
• Open branch heads:
hg log -r "head() and not closed()"
• Changesets between tags 1.3 and 1.5 mentioning "bug" that affect hgext/*:
hg log -r "1.3::1.5 and keyword(bug) and file('hgext/*')"
• Changesets committed in May 2008, sorted by user:
hg log -r "sort(date('May 2008'), user)"
• Changesets mentioning "bug" or "issue" that are not in a tagged release:
hg log -r "(keyword(bug) or keyword(issue)) and not ancestors(tag())"
• Update to the commit that bookmark @ is pointing to, without activating the bookmark (this works because the last revision of the revset is used):
hg update :@
• Show diff between tags 1.3 and 1.5 (this works because the first and the last revisions of the revset are used):
hg diff -r 1.3::1.5
It is common for machines (as opposed to humans) to consume Mercurial. This help topic describes some of the considerations for interfacing machines with Mercurial.
Choosing an Interface Machines have a choice of several methods to interface with Mercurial. These include:
• Executing the hg process
• Querying a HTTP server
• Calling out to a command server
Executing hg processes is very similar to how humans interact with Mercurial in the shell. It should already be familiar to you.
hg serve can be used to start a server. By default, this will start a "hgweb" HTTP server. This HTTP server has support for machine-readable output, such as JSON. For more, see hg help hgweb.
hg serve can also start a "command server." Clients can connect to this server and issue Mercurial commands over a special protocol.  For more details on the command server, including links to client libraries, see https://www.mercurial-scm.org/wiki/CommandServer.
hg serve based interfaces (the hgweb and command servers) have the advantage over simple hg process invocations in that they are likely more efficient. This is because there is significant overhead to spawn new Python processes.
Tip    If you need to invoke several hg processes in short order and/or performance is important to you, use of a server-based interface is highly recommended.
Environment Variables As documented in hg help environment, various environment variables influence the operation of Mercurial. The following are particularly relevant for machines consuming Mercurial:
HGPLAIN If not set, Mercurial's output could be influenced by configuration settings that impact its encoding, verbose mode, localization, etc.
It is highly recommended for machines to set this variable when invoking hg processes.
HGENCODING If not set, the locale used by Mercurial will be detected from the environment. If the determined locale does not support display of certain characters, Mercurial may render these character sequences incorrectly (often by using "?" as a placeholder for invalid characters in the current locale).
Explicitly setting this environment variable is a good practice to guarantee consistent results. "utf-8" is a good choice on UNIX-like environments.
HGRCPATH If not set, Mercurial will inherit config options from config files using the process described in hg help config. This includes inheriting user or system-wide config files.
When utmost control over the Mercurial configuration is desired, the value of HGRCPATH can be set to an explicit file with known good configs. In rare cases, the value can be set to an empty file or the null device (often /dev/null) to bypass loading of any user or system config files. Note that these approaches can have unintended consequences, as the user and system config files often define things like the username and extensions that may be required to interface with a repository.
Note that not reading the repository's configuration can have unintended consequences, as the repository config files can define things like extensions that are required for access to the repository.
Command-line Flags Mercurial's default command-line parser is designed for humans, and is not robust against malicious input. For instance, you can start a debugger by passing --debugger as an option value:
$ REV=--debugger sh -c 'hg log -r "$REV"'
This happens because several command-line flags need to be scanned without using a concrete command table, which may be modified while loading repository settings and extensions.
Since Mercurial 4.4.2, the parsing of such flags may be restricted by setting HGPLAIN=+strictflags. When this feature is enabled, all early options (e.g. -R/--repository, --cwd, --config) must be specified first amongst the other global options, and cannot be injected to an arbitrary location:
$ HGPLAIN=+strictflags hg -R "$REPO" log -r "$REV"
In earlier Mercurial versions where +strictflags isn't available, you can mitigate the issue by concatenating an option value with its flag:
$ hg log -r"$REV" --keyword="$KEYWORD"
Consuming Command Output It is common for machines to need to parse the output of Mercurial commands for relevant data. This section describes the various techniques for doing so.
Parsing Raw Command Output Likely the simplest and most effective solution for consuming command output is to simply invoke hg commands as you would as a user and parse their output.
The output of many commands can easily be parsed with tools like grep, sed, and awk.
A potential downside with parsing command output is that the output of commands can change when Mercurial is upgraded. While Mercurial does generally strive for strong backwards compatibility, command output does occasionally change. Having tests for your automated interactions with hg commands is generally recommended, but is even more important when raw command output parsing is involved.
Using Templates to Control Output Many hg commands support templatized output via the -T/--template argument. For more, see hg help templates.
Templates are useful for explicitly controlling output so that you get exactly the data you want formatted how you want it. For example, log -T {node}\n can be used to print a newline delimited list of changeset nodes instead of a human-tailored output containing authors, dates, descriptions, etc.
Tip    If parsing raw command output is too complicated, consider using templates to make your life easier.
The -T/--template argument allows specifying pre-defined styles. Mercurial ships with the machine-readable styles cbor, json, and xml, which provide CBOR, JSON, and XML output, respectively.  These are useful for producing output that is machine readable as-is.
(Mercurial 5.0 is required for CBOR style.)
Important The json and xml styles are considered experimental. While they may be attractive to use for easily obtaining machine-readable output, their behavior may change in subsequent versions.
These styles may also exhibit unexpected results when dealing with certain encodings. Mercurial treats things like filenames as a series of bytes and normalizing certain byte sequences to JSON or XML with certain encoding settings can lead to surprises.
Command Server Output If using the command server to interact with Mercurial, you are likely using an existing library/API that abstracts implementation details of the command server. If so, this interface layer may perform parsing for you, saving you the work of implementing it yourself.
Output Verbosity Commands often have varying output verbosity, even when machine readable styles are being used (e.g. -T json). Adding -v/--verbose and --debug to the command's arguments can increase the amount of data exposed by Mercurial.
An alternate way to get the data you need is by explicitly specifying a template.
Other Topics revsets Revisions sets is a functional query language for selecting a set of revisions. Think of it as SQL for Mercurial repositories. Revsets are useful for querying repositories for specific data.
See hg help revsets for more.
share extension The share extension provides functionality for sharing repository data across several working copies. It can even automatically "pool" storage for logically related repositories when cloning.
Configuring the share extension can lead to significant resource utilization reduction, particularly around disk space and the network. This is especially true for continuous integration (CI) environments.
See hg help -e share for more.
Subrepositories let you nest external repositories or projects into a parent Mercurial repository, and make commands operate on them as a group.
Mercurial currently supports Mercurial, Git, and Subversion subrepositories.
Subrepositories are made of three components:
1. Nested repository checkouts. They can appear anywhere in the parent working directory.
2. Nested repository references. They are defined in .hgsub, which should be placed in the root of working directory, and tell where the subrepository checkouts come from. Mercurial subrepositories are referenced like:
path/to/nested = https://example.com/nested/repo/path
Git and Subversion subrepos are also supported:
path/to/nested = [git]git://example.com/nested/repo/path path/to/nested = [svn]https://example.com/nested/trunk/path
where path/to/nested is the checkout location relatively to the parent Mercurial root, and https://example.com/nested/repo/path is the source repository path. The source can also reference a filesystem path.
Note that .hgsub does not exist by default in Mercurial repositories, you have to create and add it to the parent repository before using subrepositories.
3. Nested repository states. They are defined in .hgsubstate, which is placed in the root of working directory, and capture whatever information is required to restore the subrepositories to the state they were committed in a parent repository changeset. Mercurial automatically record the nested repositories states when committing in the parent repository.
Note The .hgsubstate file should not be edited manually.
Adding a Subrepository If .hgsub does not exist, create it and add it to the parent repository. Clone or checkout the external projects where you want it to live in the parent repository. Edit .hgsub and add the subrepository entry as described above. At this point, the subrepository is tracked and the next commit will record its state in .hgsubstate and bind it to the committed changeset.
Synchronizing a Subrepository Subrepos do not automatically track the latest changeset of their sources. Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update.
Thus, updating subrepos is a manual process. Simply check out target subrepo at the desired revision, test in the top-level repo, then commit in the parent repository to record the new combination.
Deleting a Subrepository To remove a subrepository from the parent repository, delete its reference from .hgsub, then remove its files.
Interaction with Mercurial Commands add    add does not recurse in subrepos unless -S/--subrepos is specified.  However, if you specify the full path of a file in a subrepo, it will be added even without -S/--subrepos specified. Subversion subrepositories are currently silently ignored.
addremove addremove does not recurse into subrepos unless -S/--subrepos is specified.  However, if you specify the full path of a directory in a subrepo, addremove will be performed on it even without -S/--subrepos being specified.  Git and Subversion subrepositories will print a warning and continue.
archive archive does not recurse in subrepositories unless -S/--subrepos is specified.
cat    Git subrepositories only support exact file matches.  Subversion subrepositories are currently ignored.
commit commit creates a consistent snapshot of the state of the entire project and its subrepositories. If any subrepositories have been modified, Mercurial will abort.  Mercurial can be made to instead commit all modified subrepositories by specifying -S/--subrepos, or setting "ui.commitsubrepos=True" in a configuration file (see hg help config).  After there are no longer any modified subrepositories, it records their state and finally commits it in the parent repository.  The --addremove option also honors the -S/--subrepos option.  However, Git and Subversion subrepositories will print a warning and abort.
diff   diff does not recurse in subrepos unless -S/--subrepos is specified.  However, if you specify the full path of a file or directory in a subrepo, it will be diffed even without -S/--subrepos being specified.  Subversion subrepositories are currently silently ignored.
files  files does not recurse into subrepos unless -S/--subrepos is specified.  However, if you specify the full path of a file or directory in a subrepo, it will be displayed even without -S/--subrepos being specified.  Git and Subversion subrepositories are currently silently ignored.
forget forget currently only handles exact file matches in subrepos.  Git and Subversion subrepositories are currently silently ignored.
incoming incoming does not recurse in subrepos unless -S/--subrepos is specified. Git and Subversion subrepositories are currently silently ignored.
outgoing outgoing does not recurse in subrepos unless -S/--subrepos is specified. Git and Subversion subrepositories are currently silently ignored.
pull   pull is not recursive since it is not clear what to pull prior to running hg update. Listing and retrieving all subrepositories changes referenced by the parent repository pulled changesets is expensive at best, impossible in the Subversion case.
push   Mercurial will automatically push all subrepositories first when the parent repository is being pushed. This ensures new subrepository changes are available when referenced by top-level repositories.  Push is a no-op for Subversion subrepositories.
serve  serve does not recurse into subrepositories unless -S/--subrepos is specified.  Git and Subversion subrepositories are currently silently ignored.
status status does not recurse into subrepositories unless -S/--subrepos is specified. Subrepository changes are displayed as regular Mercurial changes on the subrepository elements. Subversion subrepositories are currently silently ignored.
remove remove does not recurse into subrepositories unless -S/--subrepos is specified.  However, if you specify a file or directory path in a subrepo, it will be removed even without -S/--subrepos.  Git and Subversion subrepositories are currently silently ignored.
update update restores the subrepos in the state they were originally committed in target changeset. If the recorded changeset is not available in the current subrepository, Mercurial will pull it in first before updating.  This means that updating can require network access when using subrepositories.
Remapping Subrepositories Sources A subrepository source location may change during a project life, invalidating references stored in the parent repository history. To fix this, rewriting rules can be defined in parent repository hgrc file or in Mercurial configuration. See the [subpaths] section in hgrc(5) for more details.
Mercurial allows you to customize output of commands through templates. You can either pass in a template or select an existing template-style from the command line, via the --template option.
You can customize output for any "log-like" command: log, outgoing, incoming, tip, parents, and heads.
Some built-in styles are packaged with Mercurial. These can be listed with hg log --template list. Example usage:
$ hg log -r1.0::1.1 --template changelog
A template is a piece of text, with markup to invoke variable expansion:
$ hg log -r1 --template "{node}\n" b56ce7b07c52de7d5fd79fb89701ea538af65746
Keywords Strings in curly braces are called keywords. The availability of keywords depends on the exact context of the templater. These keywords are usually available for templating a log-like command:
activebookmark String. The active bookmark, if it is associated with the changeset.
author Alias for {user}
bisect String. The changeset bisection status.
bookmarks List of strings. Any bookmarks associated with the changeset. Also sets 'active', the name of the active bookmark.
branch String. The name of the branch on which the changeset was committed.
changessincelatesttag Integer. All ancestors not in the latest tag.
children List of strings. The children of the changeset.
date   Date information. The date when the changeset was committed.
desc   String. The text of the changeset description.
diffstat String. Statistics of changes with the following format: "modified files: +added/-removed lines"
extras List of dicts with key, value entries of the 'extras' field of this changeset.
file_adds List of strings. Files added by this changeset.
file_copies List of strings. Files copied in this changeset with their sources.
file_copies_switch List of strings. Like "file_copies" but displayed only if the --copied switch is set.
file_dels List of strings. Files removed by this changeset.
file_mods List of strings. Files modified by this changeset.
files  List of strings. All files modified, added, or removed by this changeset.
graphnode String. The character representing the changeset node in an ASCII revision graph.
graphwidth Integer. The width of the graph drawn by 'log --graph' or zero.
index  Integer. The current iteration of the loop. (0 indexed)
latesttag List of strings. The global tags on the most recent globally tagged ancestor of this changeset.  If no such tags exist, the list consists of the single string "null".
latesttagdistance Integer. Longest path to the latest tag.
namespaces Dict of lists. Names attached to this changeset per namespace.
negrev Integer. The repository-local changeset negative revision number, which counts in the opposite direction.
node   String. The changeset identification hash, as a 40 hexadecimal digit string.
onelinesummary String. A one-line summary for the ctx (not including trailing newline).  The default template be overridden in command-templates.oneline-summary.
p1     Changeset. The changeset's first parent. {p1.rev} for the revision number, and {p1.node} for the identification hash.
p2     Changeset. The changeset's second parent. {p2.rev} for the revision number, and {p2.node} for the identification hash.
parents List of strings. The parents of the changeset in "rev:node" format. If the changeset has only one "natural" parent (the predecessor revision) nothing is shown.
peerurls A dictionary of repository locations defined in the [paths] section of your configuration file.
phase  String. The changeset phase name.
reporoot String. The root directory of the current repository.
rev    Integer. The repository-local changeset revision number.
subrepos List of strings. Updated subrepositories in the changeset.
tags   List of strings. Any tags associated with the changeset.
termwidth Integer. The width of the current terminal.
user   String. The unmodified author of the changeset.
verbosity String. The current output verbosity in 'debug', 'quiet', 'verbose', or ''.
The "date" keyword does not produce human-readable output. If you want to use a date in your output, you can use a filter to process it. Filters are functions which return a string based on the input variable. Be sure to use the stringify filter first when you're applying a string-input filter to a list-like input variable.  You can also use a chain of filters to get the desired output:
$ hg tip --template "{date|isodate}\n" 2008-08-21 18:22 +0000
Filters List of filters:
addbreaks Any text. Add an XHTML "<br />" tag before the end of every line except the last.
age    Date. Returns a human-readable date/time difference between the given date/time and the current date/time.
basename Any text. Treats the text as a path, and returns the last component of the path after splitting by the path separator.  For example, "foo/bar/baz" becomes "baz" and "foo/bar//" becomes "".
cbor   Any object. Serializes the object to CBOR bytes.
commondir List of text. Treats each list item as file name with / as path separator and returns the longest common directory prefix shared by all list items.  Returns the empty string if no common prefix exists.
The list items are not normalized, i.e. "foo/../bar" is handled as file "bar" in the directory "foo/..". Leading slashes are ignored.
For example, ["foo/bar/baz", "foo/baz/bar"] becomes "foo" and ["foo/bar", "baz"] becomes "".
count  List or text. Returns the length as an integer.
dirname Any text. Treats the text as a path, and strips the last component of the path after splitting by the path separator.
domain Any text. Finds the first string that looks like an email address, and extracts just the domain component. Example: User <user@example.com> becomes example.com.
email  Any text. Extracts the first string that looks like an email address. Example: User <user@example.com> becomes user@example.com.
emailuser Any text. Returns the user portion of an email address.
escape Any text. Replaces the special XML/XHTML characters "&", "<" and ">" with XML entities, and filters out NUL characters.
fill68 Any text. Wraps the text to fit in 68 columns.
fill76 Any text. Wraps the text to fit in 76 columns.
firstline Any text. Returns the first line of text.
hex    Any text. Convert a binary Mercurial node identifier into its long hexadecimal representation.
hgdate Date. Returns the date as a pair of numbers: "1157407993 25200" (Unix timestamp, timezone offset).
isodate Date. Returns the date in ISO 8601 format: "2009-08-18 13:00 +0200".
isodatesec Date. Returns the date in ISO 8601 format, including seconds: "2009-08-18 13:00:13 +0200". See also the rfc3339date filter.
json   Any object. Serializes the object to a JSON formatted text.
lower  Any text. Converts the text to lowercase.
nonempty Any text. Returns '(none)' if the string is empty.
obfuscate Any text. Returns the input text rendered as a sequence of XML entities.
person Any text. Returns the name before an email address, interpreting it as per RFC 5322.
revescape Any text. Escapes all "special" characters, except @.  Forward slashes are escaped twice to prevent web servers from prematurely unescaping them. For example, "@foo bar/baz" becomes "@foo%20bar%252Fbaz".
rfc3339date Date. Returns a date using the Internet date format specified in RFC 3339: "2009-08-18T13:00:13+02:00".
rfc822date Date. Returns a date using the same format used in email headers: "Tue, 18 Aug 2009 13:00:13 +0200".
short  Changeset hash. Returns the short form of a changeset hash, i.e. a 12 hexadecimal digit string.
shortbisect Any text. Treats label as a bisection status, and returns a single-character representing the status (G: good, B: bad, S: skipped, U: untested, I: ignored). Returns single space if text is not a valid bisection status.
shortdate Date. Returns a date like "2006-09-18".
slashpath Any text. Replaces the native path separator with slash.
splitlines Any text. Split text into a list of lines.
stringify Any type. Turns the value into text by converting values into text and concatenating them.
stripdir Treat the text as path and strip a directory level, if possible. For example, "foo" and "foo/bar" becomes "foo".
tabindent Any text. Returns the text, with every non-empty line except the first starting with a tab character.
upper  Any text. Converts the text to uppercase.
urlescape Any text. Escapes all "special" characters. For example, "foo bar" becomes "foo%20bar".
user   Any text. Returns a short representation of a user name or email address.
utf8   Any text. Converts from the local character encoding to UTF-8.
Note that a filter is nothing more than a function call, i.e. expr|filter is equivalent to filter(expr).
Functions In addition to filters, there are some basic built-in functions:
config(section, name[, default]) Returns the requested hgrc config option as a string.
configbool(section, name[, default]) Returns the requested hgrc config option as a boolean.
configint(section, name[, default]) Returns the requested hgrc config option as an integer.
date(date[, fmt]) Format a date. See hg help dates for formatting strings. The default is a Unix date format, including the timezone: "Mon Sep 04 15:13:13 2006 0700".
dict([[key=]value...]) Construct a dict from key-value pairs. A key may be omitted if a value expression can provide an unambiguous name.
diff([includepattern [, excludepattern]]) Show a diff, optionally specifying files to include or exclude.
files(pattern) All files of the current changeset matching the pattern. See hg help patterns.
fill(text[, width[, initialident[, hangindent]]]) Fill many paragraphs with optional indentation. See the "fill" filter.
filter(iterable[, expr]) Remove empty elements from a list or a dict. If expr specified, it's applied to each element to test emptiness.
get(dict, key) Get an attribute/key from an object. Some keywords are complex types. This function allows you to obtain the value of an attribute on these types.
if(expr, then[, else]) Conditionally execute based on the result of an expression.
ifcontains(needle, haystack, then[, else]) Conditionally execute based on whether the item "needle" is in "haystack".
ifeq(expr1, expr2, then[, else]) Conditionally execute based on whether 2 items are equivalent.
indent(text, indentchars[, firstline]) Indents all non-empty lines with the characters given in the indentchars string. An optional third parameter will override the indent for the first line only if present.
join(list, sep) Join items in a list with a delimiter.
label(label, expr) Apply a label to generated content. Content with a label applied can result in additional post-processing, such as automatic colorization.
latesttag([pattern]) The global tags matching the given pattern on the most recent globally tagged ancestor of this changeset.  If no such tags exist, the "{tag}" template resolves to the string "null". See hg help revisions.patterns for the pattern syntax.
localdate(date[, tz]) Converts a date to the specified timezone.  The default is local date.
mailmap(author) Return the author, updated according to the value set in the .mailmap file
max(iterable) Return the max of an iterable
min(iterable) Return the min of an iterable
mod(a, b) Calculate a mod b such that a / b + a mod b == a
pad(text, width[, fillchar=' '[, left=False[, truncate=False]]]) Pad text with a fill character.
relpath(path) Convert a repository-absolute path into a filesystem path relative to the current working directory.
revset(query[, formatargs...]) Execute a revision set query. See hg help revset.
rstdoc(text, style) Format reStructuredText.
search(pattern, text) Look for the first text matching the regular expression pattern. Groups are accessible as {1}, {2}, ... in %-mapped template.
separate(sep, args...) Add a separator between non-empty arguments.
shortest(node, minlength=4) Obtain the shortest representation of a node.
startswith(pattern, text) Returns the value from the "text" argument if it begins with the content from the "pattern" argument.
strip(text[, chars]) Strip characters from a string. By default, strips all leading and trailing whitespace.
sub(pattern, replacement, expression) Perform text substitution using regular expressions.
subsetparents(rev, revset) Look up parents of the rev in the sub graph given by the revset.
word(number, text[, separator]) Return the nth word from a string.
Operators We provide a limited set of infix arithmetic operations on integers:
+ for addition - for subtraction * for multiplication / for floor division (division rounded to integer nearest -infinity)
Division fulfills the law x = x / y + mod(x, y).
Also, for any expression that returns a list, there is a list operator:
expr % "{template}"
As seen in the above example, {template} is interpreted as a template. To prevent it from being interpreted, you can use an escape character \{ or a raw string prefix, r'...'.
The dot operator can be used as a shorthand for accessing a sub item:
• expr.member is roughly equivalent to expr % '{member}' if expr returns a non-list/dict. The returned value is not stringified.
• dict.key is identical to get(dict, 'key').
Aliases New keywords and functions can be defined in the templatealias section of a Mercurial configuration file:
Arguments of the form a1, a2, etc. are substituted from the alias into the definition.
[templatealias] r = rev rn = "{r}:{node|short}" leftpad(s, w) = pad(s, w, ' ', True)
defines two symbol aliases, r and rn, and a function alias leftpad().
It's also possible to specify complete template strings, using the templates section. The syntax used is the general template string syntax.
[templates] nodedate = "{node|short}: {date(date, "%Y-%m-%d")}\n"
defines a template, nodedate, which can be called like:
$ hg log -r . -Tnodedate