neulab/tldr huggingface dataset:
HGPLAINEXCEPT This is a comma-separated list of features to preserve when HGPLAIN is enabled. Currently the following values are supported:
Don't remove aliases.
Don't disable colored output.
Preserve internationalization.
revsetalias
Don't remove revset aliases.
templatealias
Don't remove template aliases.
Don't hide progress output.
Setting HGPLAINEXCEPT to anything (even an empty string) will enable plain mode.
HGUSER This is the string used as the author of a commit. If not set, available values will be considered in this order:
• HGUSER (deprecated)
• configuration files from the HGRCPATH
• EMAIL
• interactive prompt
• LOGNAME (with @hostname appended)
(deprecated, see hg help config.ui.username)
EMAIL  May be used as the author of a commit; see HGUSER.
LOGNAME May be used as the author of a commit; see HGUSER.
VISUAL This is the name of the editor to use when committing. See EDITOR.
EDITOR Sometimes Mercurial needs to open a text file in an editor for a user to modify, for example when writing commit messages. The editor it uses is determined by looking at the environment variables HGEDITOR, VISUAL and EDITOR, in that order. The first non-empty one is chosen. If all of them are empty, the editor defaults to 'vi'.
PYTHONPATH This is used by Python to find imported modules and may need to be set appropriately if this Mercurial is not installed system-wide.
SAFELY REWRITING HISTORY (EXPERIMENTAL) Obsolescence markers make it possible to mark changesets that have been deleted or superseded in a new version of the changeset.
Unlike the previous way of handling such changes, by stripping the old changesets from the repository, obsolescence markers can be propagated between repositories. This allows for a safe and simple way of exchanging mutable history and altering it after the fact. Changeset phases are respected, such that only draft and secret changesets can be altered (see hg help phases for details).
Obsolescence is tracked using "obsolescence markers", a piece of metadata tracking which changesets have been made obsolete, potential successors for a given changeset, the moment the changeset was marked as obsolete, and the user who performed the rewriting operation. The markers are stored separately from standard changeset data can be exchanged without any of the precursor changesets, preventing unnecessary exchange of obsolescence data.
The complete set of obsolescence markers describes a history of changeset modifications that is orthogonal to the repository history of file modifications. This changeset history allows for detection and automatic resolution of edge cases arising from multiple users rewriting the same part of history concurrently.
Current feature status This feature is still in development.
Instability Rewriting changesets might introduce instability.
There are two main kinds of instability: orphaning and diverging.
Orphans are changesets left behind when their ancestors are rewritten. Divergence has two variants:
• Content-divergence occurs when independent rewrites of the same changesets lead to different results.
• Phase-divergence occurs when the old (obsolete) version of a changeset becomes public.
It is possible to prevent local creation of orphans by using the following config:
[experimental] evolution.createmarkers = true evolution.exchange = true
You can also enable that option explicitly:
[experimental] evolution.createmarkers = true evolution.exchange = true evolution.allowunstable = true
Mercurial has the ability to add new features through the use of extensions. Extensions may add new commands, add options to existing commands, change the default behavior of commands, or implement hooks.
To enable the "foo" extension, either shipped with Mercurial or in the Python search path, create an entry for it in your configuration file, like this:
[extensions] foo =
You may also specify the full path to an extension:
[extensions] myfeature = ~/.hgext/myfeature.py
See hg help config for more information on configuration files.
Extensions are not loaded by default for a variety of reasons: they can increase startup overhead; they may be meant for advanced usage only; they may provide potentially dangerous abilities (such as letting you destroy or modify history); they might not be ready for prime time; or they may alter some usual behaviors of stock Mercurial. It is thus up to the user to activate extensions as needed.
To explicitly disable an extension enabled in a configuration file of broader scope, prepend its path with !:
[extensions] # disabling extension bar residing in /path/to/extension/bar.py bar = !/path/to/extension/bar.py # ditto, but no path was supplied for extension baz baz = !
disabled extensions:
acl    hooks for controlling repository access
blackbox log repository events to a blackbox for debugging
bugzilla hooks for integrating with the Bugzilla bug tracker
censor erase file content at a given revision
churn  command to display statistics about repository history
clonebundles advertise pre-generated bundles to seed clones
closehead close arbitrary heads without checking them out first
convert import revisions from foreign VCS repositories into Mercurial
eol    automatically manage newlines in repository files
extdiff command to allow external programs to compare revisions
factotum http authentication with factotum
fastexport export repositories as git fast-import stream
githelp try mapping git commands to Mercurial commands
gpg    commands to sign and verify changesets
hgk    browse the repository in a graphical way
highlight syntax highlighting for hgweb (requires Pygments)
histedit interactive history editing
keyword expand keywords in tracked files
largefiles track large binary files
mq     manage a stack of patches
notify hooks for sending email push notifications
patchbomb command to send changesets as (a series of) patch emails
rebase command to move sets of revisions to a different ancestor
relink recreates hardlinks between repository clones
schemes extend schemes with shortcuts to repository swarms
share  share a common history between several working directories
transplant command to transplant changesets from another branch
win32mbcs allow the use of MBCS paths with problematic encodings
zeroconf discover and advertise repositories on the local network
Mercurial supports a functional language for selecting a set of files.
Like other file patterns, this pattern type is indicated by a prefix, 'set:'. The language supports a number of predicates which are joined by infix operators. Parenthesis can be used for grouping.
Identifiers such as filenames or patterns must be quoted with single or double quotes if they contain characters outside of [.*{}[]?/\_a-zA-Z0-9\x80-\xff] or if they match one of the predefined predicates. This generally applies to file patterns other than globs and arguments for predicates. Pattern prefixes such as path: may be specified without quoting.
Special characters can be used in quoted identifiers by escaping them, e.g., \n is interpreted as a newline. To prevent them from being interpreted, strings can be prefixed with r, e.g. r'...'.
See also hg help patterns.
Operators There is a single prefix operator:
not x
Files not in x. Short form is ! x.
These are the supported infix operators:
The intersection of files in x and y. Short form is x & y.
x or y
The union of files in x and y. There are two alternative short forms: x | y and x + y.
Files in x but not in y.
Predicates The following predicates are supported:
added()
File that is added according to hg status.
binary()
File that appears to be binary (contains NUL bytes).
File that is clean according to hg status.
copied()
File that is recorded as being copied.
deleted()
Alias for missing().
encoding(name)
File can be successfully decoded with the given character encoding. May not be useful for encodings other than ASCII and UTF-8.
eol(style)
File contains newlines of the given style (dos, unix, mac). Binary files are excluded, files with mixed line endings match multiple styles.
File that is marked as executable.
grep(regex)
File contains the given regular expression.
hgignore()
File that matches the active .hgignore pattern.
ignored()
File that is ignored according to hg status.
missing()
File that is missing according to hg status.
modified()
File that is modified according to hg status.
portable()
File that has a portable name. (This doesn't include filenames with case collisions.)
removed()
File that is removed according to hg status.
resolved()
File that is marked resolved according to hg resolve -l.
revs(revs, pattern)
Evaluate set in the specified revisions. If the revset match multiple revs, this will return file matching pattern in any of the revision.
size(expression)
File size matches the given expression. Examples:
• size('1k') - files from 1024 to 2047 bytes
• size('< 20k') - files less than 20480 bytes
• size('>= .5MB') - files at least 524288 bytes
• size('4k - 1MB') - files from 4096 bytes to 1048576 bytes
status(base, rev, pattern)
Evaluate predicate using status change between base and rev. Examples:
• status(3, 7, added()) - matches files added from "3" to "7"
subrepo([pattern])
Subrepositories whose paths match the given pattern.
symlink()
File that is marked as a symlink.
tracked()
File that is under Mercurial control.
unknown()
File that is unknown according to hg status.
unresolved()
File that is marked unresolved according to hg resolve -l.
Examples Some sample queries:
• Show status of files that appear to be binary in the working directory:
hg status -A "set:binary()"
• Forget files that are in .hgignore but are already tracked:
hg forget "set:hgignore() and not ignored()"
• Find text files that contain a string:
hg files "set:grep(magic) and not binary()"
• Find C files in a non-standard encoding:
hg files "set:**.c and not encoding('UTF-8')"
• Revert copies of large binary files:
hg revert "set:copied() and binary() and size('>1M')"
• Revert files that were added to the working directory:
hg revert "set:revs('wdir()', added())"
• Remove files listed in foo.lst that contain the letter a or b:
hg remove "set: listfile:foo.lst and (**a* or **b*)"
COMMAND-LINE FLAGS Most Mercurial commands accept various flags.
Flag names Flags for each command are listed in hg help for that command. Additionally, some flags, such as --repository, are global and can be used with any command - those are seen in hg help -v, and can be specified before or after the command.
Every flag has at least a long name, such as --repository. Some flags may also have a short one-letter name, such as the equivalent -R. Using the short or long name is equivalent and has the same effect. The long name may be abbreviated to any unambiguous prefix. For example, hg commit --amend can be abbreviated to hg commit --am.
Flags that have a short name can also be bundled together - for instance, to specify both --edit (short -e) and --interactive (short -i), one could use:
hg commit -ei
If any of the bundled flags takes a value (i.e. is not a boolean), it must be last, followed by the value:
hg commit -im 'Message'
Flag types Mercurial command-line flags can be strings, numbers, booleans, or lists of strings.
Specifying flag values The following syntaxes are allowed, assuming a flag 'flagname' with short name 'f':
--flagname=foo --flagname foo -f foo -ffoo
This syntax applies to all non-boolean flags (strings, numbers or lists).
Specifying boolean flags Boolean flags do not take a value parameter. To specify a boolean, use the flag name to set it to true, or the same name prefixed with 'no-' to set it to false:
hg commit --interactive hg commit --no-interactive
Specifying list flags List flags take multiple values. To specify them, pass the flag multiple times:
hg files --include mercurial --include tests
Setting flag defaults In order to set a default value for a flag in an hgrc file, it is recommended to use aliases:
[alias] commit = commit --interactive
For more information on hgrc files, see hg help config.
Overriding flags on the command line If the same non-list flag is specified multiple times on the command line, the latest specification is used:
hg commit -m "Ignored value" -m "Used value"
This includes the use of aliases - e.g., if one has:
[alias] committemp = commit -m "Ignored value"
then the following command will override that -m:
hg committemp -m "Used value"
Overriding flag defaults Every flag has a default value, and you may also set your own defaults in hgrc as described above.  Except for list flags, defaults can be overridden on the command line simply by specifying the flag in that location.
Hidden flags Some flags are not shown in a command's help by default - specifically, those that are deemed to be experimental, deprecated or advanced. To show all flags, add the --verbose flag for the help command:
hg help --verbose commit
Ancestor Any changeset that can be reached by an unbroken chain of parent changesets from a given changeset. More precisely, the ancestors of a changeset can be defined by two properties: a parent of a changeset is an ancestor, and a parent of an ancestor is an ancestor. See also: 'Descendant'.
Bookmark Bookmarks are pointers to certain commits that move when committing. They are similar to tags in that it is possible to use bookmark names in all places where Mercurial expects a changeset ID, e.g., with hg update. Unlike tags, bookmarks move along when you make a commit.
Bookmarks can be renamed, copied and deleted. Bookmarks are local, unless they are explicitly pushed or pulled between repositories. Pushing and pulling bookmarks allow you to collaborate with others on a branch without creating a named branch.
Branch (Noun) A child changeset that has been created from a parent that is not a head. These are known as topological branches, see 'Branch, topological'. If a topological branch is named, it becomes a named branch. If a topological branch is not named, it becomes an anonymous branch. See 'Branch, anonymous' and 'Branch, named'.
Branches may be created when changes are pulled from or pushed to a remote repository, since new heads may be created by these operations. Note that the term branch can also be used informally to describe a development process in which certain development is done independently of other development. This is sometimes done explicitly with a named branch, but it can also be done locally, using bookmarks or clones and anonymous branches.
Example: "The experimental branch."
(Verb) The action of creating a child changeset which results in its parent having more than one child.
Example: "I'm going to branch at X."
Branch, anonymous Every time a new child changeset is created from a parent that is not a head and the name of the branch is not changed, a new anonymous branch is created.
Branch, closed A named branch whose branch heads have all been closed.
Branch, default The branch assigned to a changeset when no name has previously been assigned.
Branch head See 'Head, branch'.
Branch, inactive If a named branch has no topological heads, it is considered to be inactive. As an example, a feature branch becomes inactive when it is merged into the default branch. The hg branches command shows inactive branches by default, though they can be hidden with hg branches --active.
NOTE: this concept is deprecated because it is too implicit. Branches should now be explicitly closed using hg commit --close-branch when they are no longer needed.
Branch, named A collection of changesets which have the same branch name. By default, children of a changeset in a named branch belong to the same named branch. A child can be explicitly assigned to a different branch. See hg help branch, hg help branches and hg commit --close-branch for more information on managing branches.
Named branches can be thought of as a kind of namespace, dividing the collection of changesets that comprise the repository into a collection of disjoint subsets. A named branch is not necessarily a topological branch. If a new named branch is created from the head of another named branch, or the default branch, but no further changesets are added to that previous branch, then that previous branch will be a branch in name only.
Branch tip See 'Tip, branch'.
Branch, topological Every time a new child changeset is created from a parent that is not a head, a new topological branch is created. If a topological branch is named, it becomes a named branch. If a topological branch is not named, it becomes an anonymous branch of the current, possibly default, branch.
Changelog A record of the changesets in the order in which they were added to the repository. This includes details such as changeset id, author, commit message, date, and list of changed files.
Changeset A snapshot of the state of the repository used to record a change.
Changeset, child The converse of parent changeset: if P is a parent of C, then C is a child of P. There is no limit to the number of children that a changeset may have.
Changeset id A SHA-1 hash that uniquely identifies a changeset. It may be represented as either a "long" 40 hexadecimal digit string, or a "short" 12 hexadecimal digit string.
Changeset, merge A changeset with two parents. This occurs when a merge is committed.
Changeset, parent A revision upon which a child changeset is based. Specifically, a parent changeset of a changeset C is a changeset whose node immediately precedes C in the DAG. Changesets have at most two parents.
Checkout (Noun) The working directory being updated to a specific revision. This use should probably be avoided where possible, as changeset is much more appropriate than checkout in this context.
Example: "I'm using checkout X."
(Verb) Updating the working directory to a specific changeset. See hg help update.
Example: "I'm going to check out changeset X."
Child changeset See 'Changeset, child'.
Close changeset See 'Head, closed branch'.
Closed branch See 'Branch, closed'.
Clone  (Noun) An entire or partial copy of a repository. The partial clone must be in the form of a revision and its ancestors.
Example: "Is your clone up to date?"
(Verb) The process of creating a clone, using hg clone.
Example: "I'm going to clone the repository."
Closed branch head See 'Head, closed branch'.
Commit (Noun) A synonym for changeset.
Example: "Is the bug fixed in your recent commit?"
(Verb) The act of recording changes to a repository. When files are committed in a working directory, Mercurial finds the differences between the committed files and their parent changeset, creating a new changeset in the repository.
Example: "You should commit those changes now."
Cset   A common abbreviation of the term changeset.
DAG    The repository of changesets of a distributed version control system (DVCS) can be described as a directed acyclic graph (DAG), consisting of nodes and edges, where nodes correspond to changesets and edges imply a parent -> child relation. This graph can be visualized by graphical tools such as hg log --graph. In Mercurial, the DAG is limited by the requirement for children to have at most two parents.
Deprecated Feature removed from documentation, but not scheduled for removal.
Default branch See 'Branch, default'.
Descendant Any changeset that can be reached by a chain of child changesets from a given changeset. More precisely, the descendants of a changeset can be defined by two properties: the child of a changeset is a descendant, and the child of a descendant is a descendant. See also: 'Ancestor'.
Diff   (Noun) The difference between the contents and attributes of files in two changesets or a changeset and the current working directory. The difference is usually represented in a standard form called a "diff" or "patch". The "git diff" format is used when the changes include copies, renames, or changes to file attributes, none of which can be represented/handled by classic "diff" and "patch".
Example: "Did you see my correction in the diff?"
(Verb) Diffing two changesets is the action of creating a diff or patch.
Example: "If you diff with changeset X, you will see what I mean."
Directory, working The working directory represents the state of the files tracked by Mercurial, that will be recorded in the next commit. The working directory initially corresponds to the snapshot at an existing changeset, known as the parent of the working directory. See 'Parent, working directory'. The state may be modified by changes to the files introduced manually or by a merge. The repository metadata exists in the .hg directory inside the working directory.
Draft  Changesets in the draft phase have not been shared with publishing repositories and may thus be safely changed by history-modifying extensions. See hg help phases.
Experimental Feature that may change or be removed at a later date.
Graph  See DAG and hg log --graph.
Head   The term 'head' may be used to refer to both a branch head or a repository head, depending on the context. See 'Head, branch' and 'Head, repository' for specific definitions.
Heads are where development generally takes place and are the usual targets for update and merge operations.
Head, branch A changeset with no descendants on the same named branch.
Head, closed branch A changeset that marks a head as no longer interesting. The closed head is no longer listed by hg heads. A branch is considered closed when all its heads are closed and consequently is not listed by hg branches.
Closed heads can be re-opened by committing new changeset as the child of the changeset that marks a head as closed.
Head, repository A topological head which has not been closed.
Head, topological A changeset with no children in the repository.
History, immutable Once committed, changesets cannot be altered.  Extensions which appear to change history actually create new changesets that replace existing ones, and then destroy the old changesets. Doing so in public repositories can result in old changesets being reintroduced to the repository.
History, rewriting The changesets in a repository are immutable. However, extensions to Mercurial can be used to alter the repository, usually in such a way as to preserve changeset contents.
Immutable history See 'History, immutable'.
Merge changeset See 'Changeset, merge'.
Manifest Each changeset has a manifest, which is the list of files that are tracked by the changeset.
Merge  Used to bring together divergent branches of work. When you update to a changeset and then merge another changeset, you bring the history of the latter changeset into your working directory. Once conflicts are resolved (and marked), this merge may be committed as a merge changeset, bringing two branches together in the DAG.
Named branch See 'Branch, named'.
Null changeset The empty changeset. It is the parent state of newly-initialized repositories and repositories with no checked out revision. It is thus the parent of root changesets and the effective ancestor when merging unrelated changesets. Can be specified by the alias 'null' or by the changeset ID '000000000000'.
Parent See 'Changeset, parent'.
Parent changeset See 'Changeset, parent'.
Parent, working directory The working directory parent reflects a virtual revision which is the child of the changeset (or two changesets with an uncommitted merge) shown by hg parents. This is changed with hg update. Other commands to see the working directory parent are hg summary and hg id. Can be specified by the alias ".".
Patch  (Noun) The product of a diff operation.
Example: "I've sent you my patch."
(Verb) The process of using a patch file to transform one changeset into another.
Example: "You will need to patch that revision."
Phase  A per-changeset state tracking how the changeset has been or should be shared. See hg help phases.
Public Changesets in the public phase have been shared with publishing repositories and are therefore considered immutable. See hg help phases.
Pull   An operation in which changesets in a remote repository which are not in the local repository are brought into the local repository. Note that this operation without special arguments only updates the repository, it does not update the files in the working directory. See hg help pull.
Push   An operation in which changesets in a local repository which are not in a remote repository are sent to the remote repository. Note that this operation only adds changesets which have been committed locally to the remote repository. Uncommitted changes are not sent. See hg help push.
Repository The metadata describing all recorded states of a collection of files. Each recorded state is represented by a changeset. A repository is usually (but not always) found in the .hg subdirectory of a working directory. Any recorded state can be recreated by "updating" a working directory to a specific changeset.
Repository head See 'Head, repository'.
Revision A state of the repository at some point in time. Earlier revisions can be updated to by using hg update.  See also 'Revision number'; See also 'Changeset'.
Revision number This integer uniquely identifies a changeset in a specific repository. It represents the order in which changesets were added to a repository, starting with revision number 0. Note that the revision number may be different in each clone of a repository. To identify changesets uniquely between different clones, see 'Changeset id'.
Revlog History storage mechanism used by Mercurial. It is a form of delta encoding, with occasional full revision of data followed by delta of each successive revision. It includes data and an index pointing to the data.
Rewriting history See 'History, rewriting'.
Root   A changeset that has only the null changeset as its parent. Most repositories have only a single root changeset.
Secret Changesets in the secret phase may not be shared via push, pull, or clone. See hg help phases.
Tag    An alternative name given to a changeset. Tags can be used in all places where Mercurial expects a changeset ID, e.g., with hg update. The creation of a tag is stored in the history and will thus automatically be shared with other using push and pull.
Tip    The changeset with the highest revision number. It is the changeset most recently added in a repository.
Tip, branch The head of a given branch with the highest revision number. When a branch name is used as a revision identifier, it refers to the branch tip. See also 'Branch, head'. Note that because revision numbers may be different in different repository clones, the branch tip may be different in different cloned repositories.
Update (Noun) Another synonym of changeset.
Example: "I've pushed an update."
(Verb) This term is usually used to describe updating the state of the working directory to that of a specific changeset. See hg help update.
Example: "You should update."
Working directory See 'Directory, working'.
Working directory parent See 'Parent, working directory'.
Synopsis The Mercurial system uses a file called .hgignore in the root directory of a repository to control its behavior when it searches for files that it is not currently tracking.
Description The working directory of a Mercurial repository will often contain files that should not be tracked by Mercurial. These include backup files created by editors and build products created by compilers.  These files can be ignored by listing them in a .hgignore file in the root of the working directory. The .hgignore file must be created manually. It is typically put under version control, so that the settings will propagate to other repositories with push and pull.
An untracked file is ignored if its path relative to the repository root directory, or any prefix path of that path, is matched against any pattern in .hgignore.
For example, say we have an untracked file, file.c, at a/b/file.c inside our repository. Mercurial will ignore file.c if any pattern in .hgignore matches a/b/file.c, a/b or a.
In addition, a Mercurial configuration file can reference a set of per-user or global ignore files. See the ignore configuration key on the [ui] section of hg help config for details of how to configure these files.
To control Mercurial's handling of files that it manages, many commands support the -I and -X options; see hg help <command> and hg help patterns for details.
Files that are already tracked are not affected by .hgignore, even if they appear in .hgignore. An untracked file X can be explicitly added with hg add X, even if X would be excluded by a pattern in .hgignore.
Syntax An ignore file is a plain text file consisting of a list of patterns, with one pattern per line. Empty lines are skipped. The # character is treated as a comment character, and the \ character is treated as an escape character.
Mercurial supports several pattern syntaxes. The default syntax used is Python/Perl-style regular expressions.
To change the syntax used, use a line of the following form:
syntax: NAME
where NAME is one of the following:
Regular expression, Python/Perl syntax.
Shell-style glob.
rootglob
A variant of glob that is rooted (see below).
The chosen syntax stays in effect when parsing all patterns that follow, until another syntax is selected.
Neither glob nor regexp patterns are rooted. A glob-syntax pattern of the form *.c will match a file ending in .c in any directory, and a regexp pattern of the form \.c$ will do the same. To root a regexp pattern, start it with ^. To get the same effect with glob-syntax, you have to use rootglob.
Subdirectories can have their own .hgignore settings by adding subinclude:path/to/subdir/.hgignore to the root .hgignore. See hg help patterns for details on subinclude: and include:.
Note   Patterns specified in other than .hgignore are always rooted. Please see hg help patterns for details.
Example Here is an example ignore file.
# use glob syntax. syntax: glob
*.elc *.pyc *~
# switch to regexp syntax. syntax: regexp ^\.pc/
Debugging Use the debugignore command to see if and why a file is ignored, or to see the combined ignore pattern. See hg help debugignore for details.
Mercurial's internal web server, hgweb, can serve either a single repository, or a tree of repositories. In the second case, repository paths and global options can be defined using a dedicated configuration file common to hg serve, hgweb.wsgi, hgweb.cgi and hgweb.fcgi.
This file uses the same syntax as other Mercurial configuration files but recognizes only the following sections:
• web
• paths
• collections
The web options are thoroughly described in hg help config.
The paths section maps URL paths to paths of repositories in the filesystem. hgweb will not expose the filesystem directly - only Mercurial repositories can be published and only according to the configuration.
The left hand side is the path in the URL. Note that hgweb reserves subpaths like rev or file, try using different names for nested repositories to avoid confusing effects.
The right hand side is the path in the filesystem. If the specified path ends with * or ** the filesystem will be searched recursively for repositories below that point.  With * it will not recurse into the repositories it finds (except for .hg/patches).  With ** it will also search inside repository working directories and possibly find subrepositories.
In this example:
[paths] /projects/a = /srv/tmprepos/a /projects/b = c:/repos/b / = /srv/repos/* /user/bob = /home/bob/repos/**
• The first two entries make two repositories in different directories appear under the same directory in the web interface
• The third entry will publish every Mercurial repository found in /srv/repos/, for instance the repository /srv/repos/quux/ will appear as http://server/quux/
• The fourth entry will publish both http://server/user/bob/quux/ and http://server/user/bob/quux/testsubrepo/
The collections section is deprecated and has been superseded by paths.
URLs and Common Arguments URLs under each repository have the form /{command}[/{arguments}] where {command} represents the name of a command or handler and {arguments} represents any number of additional URL parameters to that command.
The web server has a default style associated with it. Styles map to a collection of named templates. Each template is used to render a specific piece of data, such as a changeset or diff.
The style for the current request can be overridden two ways. First, if {command} contains a hyphen (-), the text before the hyphen defines the style. For example, /atom-log will render the log command handler with the atom style. The second way to set the style is with the style query string argument. For example, /log?style=atom. The hyphenated URL parameter is preferred.
Not all templates are available for all styles. Attempting to use a style that doesn't have all templates defined may result in an error rendering the page.
Many commands take a {revision} URL parameter. This defines the changeset to operate on. This is commonly specified as the short, 12 digit hexadecimal abbreviation for the full 40 character unique revision identifier. However, any value described by hg help revisions typically works.
Commands and URLs The following web commands and their URLs are available:
/annotate/{revision}/{path} Show changeset information for each line in a file.
The ignorews, ignorewsamount, ignorewseol, and ignoreblanklines query string arguments have the same meaning as their [annotate] config equivalents. It uses the hgrc boolean parsing logic to interpret the value. e.g. 0 and false are false and 1 and true are true. If not defined, the server default settings are used.
The fileannotate template is rendered.
/archive/{revision}.{format}[/{path}] Obtain an archive of repository content.
The content and type of the archive is defined by a URL path parameter. format is the file extension of the archive type to be generated. e.g. zip or tar.bz2. Not all archive types may be allowed by your server configuration.
The optional path URL parameter controls content to include in the archive. If omitted, every file in the specified revision is present in the archive. If included, only the specified file or contents of the specified directory will be included in the archive.
No template is used for this handler. Raw, binary content is generated.
/bookmarks Show information about bookmarks.
No arguments are accepted.
The bookmarks template is rendered.
/branches Show information about branches.
All known branches are contained in the output, even closed branches.
The branches template is rendered.
/changelog[/{revision}] Show information about multiple changesets.
If the optional revision URL argument is absent, information about all changesets starting at tip will be rendered. If the revision argument is present, changesets will be shown starting from the specified revision.
If revision is absent, the rev query string argument may be defined. This will perform a search for changesets.
The argument for rev can be a single revision, a revision set, or a literal keyword to search for in changeset data (equivalent to hg log -k ).
The revcount query string argument defines the maximum numbers of changesets to render.
For non-searches, the changelog template will be rendered.
/changeset[/{revision}] Show information about a single changeset.
A URL path argument is the changeset identifier to show. See hg help revisions for possible values. If not defined, the tip changeset will be shown.
The changeset template is rendered. Contents of the changesettag, changesetbookmark, filenodelink, filenolink, and the many templates related to diffs may all be used to produce the output.
/comparison/{revision}/{path} Show a comparison between the old and new versions of a file from changes made on a particular revision.
This is similar to the diff handler. However, this form features a split or side-by-side diff rather than a unified diff.
The context query string argument can be used to control the lines of context in the diff.
The filecomparison template is rendered.
/diff/{revision}/{path} Show how a file changed in a particular commit.
The filediff template is rendered.
This handler is registered under both the /diff and /filediff paths. /diff is used in modern code.
/file/{revision}[/{path}] Show information about a directory or file in the repository.
Info about the path given as a URL parameter will be rendered.
If path is a directory, information about the entries in that directory will be rendered. This form is equivalent to the manifest handler.
If path is a file, information about that file will be shown via the filerevision template.
If path is not defined, information about the root directory will be rendered.
/filelog/{revision}/{path} Show information about the history of a file in the repository.
The revcount query string argument can be defined to control the maximum number of entries to show.
The filelog template will be rendered.
/graph[/{revision}] Show information about the graphical topology of the repository.
Information rendered by this handler can be used to create visual representations of repository topology.
The revision URL parameter controls the starting changeset. If it's absent, the default is tip.
The revcount query string argument can define the number of changesets to show information for.
The graphtop query string argument can specify the starting changeset for producing jsdata variable that is used for rendering graph in JavaScript. By default it has the same value as revision.
This handler will render the graph template.
/help[/{topic}] Render help documentation.
This web command is roughly equivalent to hg help. If a topic is defined, that help topic will be rendered. If not, an index of available help topics will be rendered.
The help template will be rendered when requesting help for a topic. helptopics will be rendered for the index of help topics.
/log[/{revision}[/{path}]] Show repository or file history.
For URLs of the form /log/{revision}, a list of changesets starting at the specified changeset identifier is shown. If {revision} is not defined, the default is tip. This form is equivalent to the changelog handler.
For URLs of the form /log/{revision}/{file}, the history for a specific file will be shown. This form is equivalent to the filelog handler.
/manifest[/{revision}[/{path}]] Show information about a directory.
If the URL path arguments are omitted, information about the root directory for the tip changeset will be shown.
Because this handler can only show information for directories, it is recommended to use the file handler instead, as it can handle both directories and files.
The manifest template will be rendered for this handler.
/shortlog Show basic information about a set of changesets.
This accepts the same parameters as the changelog handler. The only difference is the shortlog template will be rendered instead of the changelog template.
/summary Show a summary of repository state.
Information about the latest changesets, bookmarks, tags, and branches is captured by this handler.
The summary template is rendered.
/tags Show information about tags.
The tags template is rendered.
To access a subtopic, use "hg help internals.{subtopic-name}"
bid-merge Bid Merge Algorithm
bundle2 Bundle2
bundles Bundles
cbor   CBOR
censor Censor
changegroups Changegroups
config Config Registrar
extensions Extension API
mergestate Mergestate
requirements Repository Requirements
revlogs Revision Logs
wireprotocol Wire Protocol
wireprotocolrpc Wire Protocol RPC
wireprotocolv2 Wire Protocol Version 2
To merge files Mercurial uses merge tools.
A merge tool combines two different versions of a file into a merged file. Merge tools are given the two files and the greatest common ancestor of the two file versions, so they can determine the changes made on both branches.
Merge tools are used both for hg resolve, hg merge, hg update, hg backout and in several extensions.
Usually, the merge tool tries to automatically reconcile the files by combining all non-overlapping changes that occurred separately in the two different evolutions of the same initial base file. Furthermore, some interactive merge programs make it easier to manually resolve conflicting merges, either in a graphical way, or by inserting some conflict markers. Mercurial does not include any interactive merge programs but relies on external tools for that.
Available merge tools External merge tools and their properties are configured in the merge-tools configuration section - see hgrc(5) - but they can often just be named by their executable.
A merge tool is generally usable if its executable can be found on the system and if it can handle the merge. The executable is found if it is an absolute or relative executable path or the name of an application in the executable search path. The tool is assumed to be able to handle the merge if it can handle symlinks if the file is a symlink, if it can handle binary files if the file is binary, and if a GUI is available if the tool requires a GUI.
There are some internal merge tools which can be used. The internal merge tools are:
:dump
Creates three versions of the files to merge, containing the contents of local, other and base. These files can then be used to perform a merge manually. If the file to be merged is named a.txt, these files will accordingly be named a.txt.local, a.txt.other and a.txt.base and they will be placed in the same directory as a.txt.
This implies premerge. Therefore, files aren't dumped, if premerge runs successfully. Use :forcedump to forcibly write files out.
(actual capabilities: binary, symlink)
:fail
Rather than attempting to merge files that were modified on both branches, it marks them as unresolved. The resolve command must be used to resolve these conflicts.
:forcedump
Creates three versions of the files as same as :dump, but omits premerge.
:local
Uses the local p1() version of files as the merged version.
:merge
Uses the internal non-interactive simple merge algorithm for merging files. It will fail if there are any conflicts and leave markers in the partially merged file. Markers will have two sections, one for each side of merge.
:merge-local
Like :merge, but resolve all conflicts non-interactively in favor of the local p1() changes.
:merge-other
Like :merge, but resolve all conflicts non-interactively in favor of the other p2() changes.
:merge3
Uses the internal non-interactive simple merge algorithm for merging files. It will fail if there are any conflicts and leave markers in the partially merged file. Marker will have three sections, one from each side of the merge and one for the base content.
:mergediff
Uses the internal non-interactive simple merge algorithm for merging files. It will fail if there are any conflicts and leave markers in the partially merged file. The marker will have two sections, one with the content from one side of the merge, and one with a diff from the base content to the content on the other side. (experimental)
Uses the other p2() version of files as the merged version.
:prompt
Asks the user which of the local p1() or the other p2() version to keep as the merged version.
:tagmerge
Uses the internal tag merge algorithm (experimental).
:union
Uses the internal non-interactive simple merge algorithm for merging files. It will use both left and right sides for conflict regions.  No markers are inserted.
Internal tools are always available and do not require a GUI but will by default not handle symlinks or binary files. See next section for detail about "actual capabilities" described above.
Choosing a merge tool Mercurial uses these rules when deciding which merge tool to use:
1. If a tool has been specified with the --tool option to merge or resolve, it is used.  If it is the name of a tool in the merge-tools configuration, its configuration is used. Otherwise the specified tool must be executable by the shell.
2. If the HGMERGE environment variable is present, its value is used and must be executable by the shell.
3. If the filename of the file to be merged matches any of the patterns in the merge-patterns configuration section, the first usable merge tool corresponding to a matching pattern is used.
4. If ui.merge is set it will be considered next. If the value is not the name of a configured tool, the specified value is used and must be executable by the shell. Otherwise the named tool is used if it is usable.
5. If any usable merge tools are present in the merge-tools configuration section, the one with the highest priority is used.
6. If a program named hgmerge can be found on the system, it is used - but it will by default not be used for symlinks and binary files.
7. If the file to be merged is not binary and is not a symlink, then internal :merge is used.
8. Otherwise, :prompt is used.
For historical reason, Mercurial treats merge tools as below while examining rules above.
┌───────────┬────────────────┬────────┬─────────┐ │step       │ specified via  │ binary │ symlink │ ├───────────┼────────────────┼────────┼─────────┤ │           │ --tool         │ o/o    │ o/o     │ │       1.  │                │        │         │ ├───────────┼────────────────┼────────┼─────────┤ │           │ HGMERGE        │ o/o    │ o/o     │ │       2.  │                │        │         │ ├───────────┼────────────────┼────────┼─────────┤ │           │ merge-patterns │ o/o(*) │ x/?(*)  │ │       3.  │                │        │         │ ├───────────┼────────────────┼────────┼─────────┤ │           │ ui.merge       │ x/?(*) │ x/?(*)  │ │       4.  │                │        │         │ └───────────┴────────────────┴────────┴─────────┘
Each capability column indicates Mercurial behavior for internal/external merge tools at examining each rule.
• "o": "assume that a tool has capability"
• "x": "assume that a tool does not have capability"
• "?": "check actual capability of a tool"
If merge.strict-capability-check configuration is true, Mercurial checks capabilities of merge tools strictly in (*) cases above (= each capability column becomes "?/?"). It is false by default for backward compatibility.
Note   After selecting a merge program, Mercurial will by default attempt to merge the files using a simple merge algorithm first. Only if it doesn't succeed because of conflicting changes will Mercurial actually execute the merge program. Whether to use the simple merge algorithm first can be controlled by the premerge setting of the merge tool. Premerge is enabled by default unless the file is binary or a symlink.
See the merge-tools and ui sections of hgrc(5) for details on the configuration of merge tools.
Some Mercurial commands can produce a lot of output, and Mercurial will attempt to use a pager to make those commands more pleasant.
To set the pager that should be used, set the application variable:
[pager] pager = less -FRX
If no pager is set in the user or repository configuration, Mercurial uses the environment variable $PAGER. If $PAGER is not set, pager.pager from the default or system configuration is used. If none of these are set, a default pager will be used, typically less on Unix and more on Windows.
On Windows, more is not color aware, so using it effectively disables color.  MSYS and Cygwin shells provide less as a pager, which can be configured to support ANSI color codes.  See hg help config.color.pagermode to configure the color mode when invoking a pager.
You can disable the pager for certain commands by adding them to the pager.ignore list:
[pager] ignore = version, help, update
To ignore global commands like hg version or hg help, you have to specify them in your user configuration file.
To control whether the pager is used at all for an individual command, you can use --pager=<value>:
• use as needed: auto.
• require the pager: yes or on.
• suppress the pager: no or off (any unrecognized value will also work).
To globally turn off all attempts to use a pager, set:
[ui] paginate = never
which will prevent the pager from running.
Mercurial accepts several notations for identifying one or more files at a time.
By default, Mercurial treats filenames as shell-style extended glob patterns.
Alternate pattern notations must be specified explicitly.
Note   Patterns specified in .hgignore are not rooted.  Please see hg help hgignore for details.
To use a plain path name without any pattern matching, start it with path:. These path names must completely match starting at the current repository root, and when the path points to a directory, it is matched recursively. To match all files in a directory non-recursively (not including any files in subdirectories), rootfilesin: can be used, specifying an absolute path (relative to the repository root).
To use an extended glob, start a name with glob:. Globs are rooted at the current directory; a glob such as *.c will only match files in the current directory ending with .c. rootglob: can be used instead of glob: for a glob that is rooted at the root of the repository.