neulab/tldr huggingface dataset:
In normal clone mode, the remote normalizes repository data into a common exchange format and the receiving end translates this data into its local storage format. --stream activates a different clone mode that essentially copies repository files from the remote with minimal data processing. This significantly reduces the CPU cost of a clone both remotely and locally.  However, it often increases the transferred data size by 30-40%. This can result in substantially faster clones where I/O throughput is plentiful, especially for larger repositories. A side-effect of --stream clones is that storage settings and requirements on the remote are applied locally: a modern client may inherit legacy or inefficient storage used by the remote or a legacy Mercurial client may not be able to clone from a modern Mercurial remote.
Note   Specifying a tag will include the tagged changeset but not the changeset containing the tag.
For efficiency, hardlinks are used for cloning whenever the source and destination are on the same filesystem (note this applies only to the repository data, not to the working directory). Some filesystems, such as AFS, implement hardlinking incorrectly, but do not report errors. In these cases, use the --pull option to avoid hardlinking.
Mercurial will update the working directory to the first applicable revision from this list:
a. null if -U or the source repository has no changesets
b. if -u . and the source repository is local, the first parent of the source repository's working directory
c. the changeset specified with -u (if a branch name, this means the latest head of that branch)
d. the changeset specified with -r
e. the tipmost head specified with -b
f. the tipmost head specified with the url#branch source syntax
g. the revision marked with the '@' bookmark, if present
h. the tipmost head of the default branch
i. tip
When cloning from servers that support it, Mercurial may fetch pre-generated data from a server-advertised URL or inline from the same stream. When this is done, hooks operating on incoming changesets and changegroups may fire more than once, once for each pre-generated bundle and as well as for any additional remaining data. In addition, if an error occurs, the repository may be rolled back to a partial clone. This behavior may change in future releases.  See hg help -e clonebundles for more.
• clone a remote repository to a new directory named hg/:
hg clone https://www.mercurial-scm.org/repo/hg/
• create a lightweight local clone:
hg clone project/ project-feature/
• clone from an absolute path on an ssh server (note double-slash):
hg clone ssh://user@server//home/projects/alpha/
• do a streaming clone while checking out a specified version:
hg clone --stream http://server/repo -u 1.5
• create a repository without changesets after a particular revision:
hg clone -r 04e544 experimental/ good/
• clone (and track) a particular named branch:
hg clone https://www.mercurial-scm.org/repo/hg/#stable
See hg help urls for details on specifying URLs.
Returns 0 on success.
-U, --noupdate the clone will include an empty working directory (only a repository)
-u,--updaterev <REV> revision, tag, or branch to check out
-r,--rev <REV[+]> do not clone everything, but include this changeset and its ancestors
-b,--branch <BRANCH[+]> do not clone everything, but include this branch's changesets and their ancestors
--pull use pull protocol to copy metadata
--uncompressed an alias to --stream (DEPRECATED)
--stream clone with minimal data processing
-e,--ssh <CMD> specify ssh command to use
--remotecmd <CMD> specify hg command to run on the remote side
--insecure do not verify server certificate (ignoring web.cacerts config)
init create a new repository in the given directory:
hg init [-e CMD] [--remotecmd CMD] [DEST]
Initialize a new repository in the given directory. If the given directory does not exist, it will be created.
If no directory is given, the current directory is used.
It is possible to specify an ssh:// URL as the destination.  See hg help urls for more information.
Remote repository management incoming show new changesets found in source:
hg incoming [-p] [-n] [-M] [-f] [-r REV]... [--bundle FILENAME] [SOURCE]
Show new changesets found in the specified path/URL or the default pull location. These are the changesets that would have been pulled by hg pull at the time you issued this command.
See pull for valid source format details.
With -B/--bookmarks, the result of bookmark comparison between local and remote repositories is displayed. With -v/--verbose, status is also displayed for each bookmark like below:
BM1               01234567890a added BM2               1234567890ab advanced BM3               234567890abc diverged BM4               34567890abcd changed
The action taken locally when pulling depends on the status of each bookmark:
pull will create it
pull will update it
pull will create a divergent bookmark
result depends on remote changesets
From the point of view of pulling behavior, bookmark existing only in the remote repository are treated as added, even if it is in fact locally deleted.
For remote repository, using --bundle avoids downloading the changesets twice if the incoming is followed by a pull.
• show incoming changes with patches and full description:
hg incoming -vp
• show incoming changes excluding merges, store a bundle:
hg in -vpM --bundle incoming.hg hg pull incoming.hg
• briefly list changes inside a bundle:
hg in changes.hg -T "{desc|firstline}\n"
Returns 0 if there are incoming changes, 1 otherwise.
-f, --force run even if remote repository is unrelated
-n, --newest-first show newest record first
--bundle <FILE> file to store the bundles into
-r,--rev <REV[+]> a remote changeset intended to be added
-B, --bookmarks compare bookmarks
-b,--branch <BRANCH[+]> a specific branch you would like to pull
-p, --patch show patch
-g, --git use git extended diff format
-l,--limit <NUM> limit number of changes displayed
-M, --no-merges do not show merges
--stat output diffstat-style summary of changes
-G, --graph show the revision DAG
--style <STYLE> display using template map file (DEPRECATED)
-T,--template <TEMPLATE> display with template
-S, --subrepos recurse into subrepositories
aliases: in
outgoing show changesets not found in the destination:
hg outgoing [-M] [-p] [-n] [-f] [-r REV]... [DEST]...
Show changesets not found in the specified destination repository or the default push location. These are the changesets that would be pushed if a push was requested.
See pull for details of valid destination formats.
BM1               01234567890a added BM2                            deleted BM3               234567890abc advanced BM4               34567890abcd diverged BM5               4567890abcde changed
The action taken when pushing depends on the status of each bookmark:
push with -B will create it
push with -B will delete it
push will update it
push with -B will update it
From the point of view of pushing behavior, bookmarks existing only in the remote repository are treated as deleted, even if it is in fact added remotely.
Returns 0 if there are outgoing changes, 1 otherwise.
-f, --force run even when the destination is unrelated
-r,--rev <REV[+]> a changeset intended to be included in the destination
-b,--branch <BRANCH[+]> a specific branch you would like to push
aliases: out
paths show aliases for remote repositories:
hg paths [NAME]
Show definition of symbolic path name NAME. If no name is given, show definition of all available names.
Option -q/--quiet suppresses all output when searching for NAME and shows only the path names when listing all definitions.
Path names are defined in the [paths] section of your configuration file and in /etc/mercurial/hgrc. If run inside a repository, .hg/hgrc is used, too.
The path names default and default-push have a special meaning.  When performing a push or pull operation, they are used as fallbacks if no location is specified on the command-line.  When default-push is set, it will be used for push and default will be used for pull; otherwise default is used as the fallback for both.  When cloning a repository, the clone source is written as default in .hg/hgrc.
Note   default and default-push apply to all inbound (e.g.  hg incoming) and outbound (e.g. hg outgoing, hg email and hg bundle) operations.
See hg help urls for more information.
Template:
The following keywords are supported. See also hg help templates.
name   String. Symbolic name of the path alias.
pushurl String. URL for push operations.
url    String. URL or directory path for the other operations.
pull pull changes from the specified source:
hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE]...
Pull changes from a remote repository to a local one.
This finds all changes from the repository at the specified path or URL and adds them to a local repository (the current one unless -R is specified). By default, this does not update the copy of the project in the working directory.
When cloning from servers that support it, Mercurial may fetch pre-generated data. When this is done, hooks operating on incoming changesets and changegroups may fire more than once, once for each pre-generated bundle and as well as for any additional remaining data. See hg help -e clonebundles for more.
Use hg incoming if you want to see what would have been added by a pull at the time you issued this command. If you then decide to add those changes to the repository, you should use hg pull -r X where X is the last changeset listed by hg incoming.
If SOURCE is omitted, the 'default' path will be used.  See hg help urls for more information.
If multiple sources are specified, they will be pulled sequentially as if the command was run multiple time. If --update is specify and the command will stop at the first failed --update.
Specifying bookmark as . is equivalent to specifying the active bookmark's name.
Returns 0 on success, 1 if an update had unresolved files.
-u, --update update to new branch head if new descendants were pulled
-f, --force run even when remote repository is unrelated
--confirm confirm pull before applying changes
-B,--bookmark <BOOKMARK[+]> bookmark to pull
push push changes to the specified destination:
hg push [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]...
Push changesets from the local repository to the specified destination.
This operation is symmetrical to pull: it is identical to a pull in the destination repository from the current one.
By default, push will not allow creation of new heads at the destination, since multiple heads would make it unclear which head to use. In this situation, it is recommended to pull and merge before pushing.
Use --new-branch if you want to allow push to create a new named branch that is not present at the destination. This allows you to only create a new branch without forcing other changes.
Note   Extra care should be taken with the -f/--force option, which will push all new heads on all branches, an action which will almost always cause confusion for collaborators.
If -r/--rev is used, the specified revision and all its ancestors will be pushed to the remote repository.
If -B/--bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository. Specifying . is equivalent to specifying the active bookmark's name. Use the --all-bookmarks option for pushing all current bookmarks.
Please see hg help urls for important details about ssh:// URLs. If DESTINATION is omitted, a default path will be used.
When passed multiple destinations, push will process them one after the other, but stop should an error occur.
The --pushvars option sends strings to the server that become environment variables prepended with HG_USERVAR_. For example, --pushvars ENABLE_FEATURE=true, provides the server side hooks with HG_USERVAR_ENABLE_FEATURE=true as part of their environment.
pushvars can provide for user-overridable hooks as well as set debug levels. One example is having a hook that blocks commits containing conflict markers, but enables the user to override the hook if the file is using conflict markers for testing purposes or the file format has strings that look like conflict markers.
By default, servers will ignore --pushvars. To enable it add the following to your configuration file:
[push] pushvars.server = true
Returns 0 if push was successful, 1 if nothing to push.
-f, --force force push
-B,--bookmark <BOOKMARK[+]> bookmark to push
--all-bookmarks push all bookmarks (EXPERIMENTAL)
--new-branch allow pushing a new branch
--pushvars <VALUE[+]> variables that can be sent to server (ADVANCED)
--publish push the changeset as public (EXPERIMENTAL)
serve start stand-alone webserver:
hg serve [OPTION]...
Start a local HTTP repository browser and pull server. You can use this for ad-hoc sharing and browsing of repositories. It is recommended to use a real web server to serve a repository for longer periods of time.
Please note that the server does not implement access control.  This means that, by default, anybody can read from the server and nobody can write to it by default. Set the web.allow-push option to * to allow everybody to push to the server. You should use a real web server if you need to authenticate users.
By default, the server logs accesses to stdout and errors to stderr. Use the -A/--accesslog and -E/--errorlog options to log to files.
To have the server choose a free port number to listen on, specify a port number of 0; in this case, the server will print the port number it uses.
-A,--accesslog <FILE> name of access log file to write to
-d, --daemon run server in background
--daemon-postexec <VALUE[+]> used internally by daemon mode
-E,--errorlog <FILE> name of error log file to write to
-p,--port <PORT> port to listen on (default: 8000)
-a,--address <ADDR> address to listen on (default: all interfaces)
--prefix <PREFIX> prefix path to serve from (default: server root)
-n,--name <NAME> name to show in web pages (default: working directory)
--web-conf <FILE> name of the hgweb config file (see 'hg help hgweb')
--webdir-conf <FILE> name of the hgweb config file (DEPRECATED)
--pid-file <FILE> name of file to write process ID to
--stdio for remote clients (ADVANCED)
--cmdserver <MODE> for remote clients (ADVANCED)
-t,--templates <TEMPLATE> web templates to use
--style <STYLE> template style to use
-6, --ipv6 use IPv6 in addition to IPv4
--certificate <FILE> SSL certificate file
--print-url start and print only the URL
Change creation commit commit the specified files or all outstanding changes:
hg commit [OPTION]... [FILE]...
Commit changes to the given files into the repository. Unlike a centralized SCM, this operation is a local operation. See hg push for a way to actively distribute your changes.
If a list of files is omitted, all changes reported by hg status will be committed.
If you are committing the result of a merge, do not provide any filenames or -I/-X filters.
If no commit message is specified, Mercurial starts your configured editor where you can enter a message. In case your commit fails, you will find a backup of your message in .hg/last-message.txt.
The --close-branch flag can be used to mark the current branch head closed. When all heads of a branch are closed, the branch will be considered closed and no longer listed.
The --amend flag can be used to amend the parent of the working directory with a new commit that contains the changes in the parent in addition to those currently reported by hg status, if there are any. The old commit is stored in a backup bundle in .hg/strip-backup (see hg help bundle and hg help unbundle on how to restore it).
Message, user and date are taken from the amended commit unless specified. When a message isn't specified on the command line, the editor will open with the message of the amended commit.
It is not possible to amend public changesets (see hg help phases) or changesets that have children.
See hg help dates for a list of formats valid for -d/--date.
Returns 0 on success, 1 if nothing changed.
• commit all files ending in .py:
hg commit --include "set:**.py"
• commit all non-binary files:
hg commit --exclude "set:binary()"
• amend the current commit and set the date to now:
hg commit --amend --date now
-A, --addremove mark new/missing files as added/removed before committing
--close-branch mark a branch head as closed
--amend amend the parent of the working directory
-s, --secret use the secret phase for committing
-e, --edit invoke editor on commit messages
--force-close-branch forcibly close branch from a non-head changeset (ADVANCED)
-i, --interactive use interactive mode
-I,--include <PATTERN[+]> include names matching the given patterns
-X,--exclude <PATTERN[+]> exclude names matching the given patterns
-m,--message <TEXT> use text as commit message
-l,--logfile <FILE> read commit message from file
-d,--date <DATE> record the specified date as commit date
-u,--user <USER> record the specified user as committer
aliases: ci
Change manipulation abort abort an unfinished operation (EXPERIMENTAL):
hg abort
Aborts a multistep operation like graft, histedit, rebase, merge, and unshelve if they are in an unfinished state.
use --dry-run/-n to dry run the command.
-n, --dry-run do not perform actions, just print output
backout reverse effect of earlier changeset:
hg backout [OPTION]... [-r] REV
Prepare a new changeset with the effect of REV undone in the current working directory. If no conflicts were encountered, it will be committed immediately.
If REV is the parent of the working directory, then this new changeset is committed automatically (unless --no-commit is specified).
Note   hg backout cannot be used to fix either an unwanted or incorrect merge.
• Reverse the effect of the parent of the working directory.  This backout will be committed immediately:
hg backout -r .
• Reverse the effect of previous bad revision 23:
hg backout -r 23
• Reverse the effect of previous bad revision 23 and leave changes uncommitted:
hg backout -r 23 --no-commit hg commit -m "Backout revision 23"
By default, the pending changeset will have one parent, maintaining a linear history. With --merge, the pending changeset will instead have two parents: the old parent of the working directory and a new child of REV that simply undoes REV.
Before version 1.7, the behavior without --merge was equivalent to specifying --merge followed by hg update --clean . to cancel the merge and leave the child of REV as a head to be merged separately.
See hg help revert for a way to restore files to the state of another revision.
Returns 0 on success, 1 if nothing to backout or there are unresolved files.
--merge merge with old dirstate parent after backout
--commit commit if no conflicts were encountered (DEPRECATED)
--no-commit do not commit
--parent <REV> parent to choose when backing out merge (DEPRECATED)
-r,--rev <REV> revision to backout
-t,--tool <TOOL> specify merge tool
continue resumes an interrupted operation (EXPERIMENTAL):
hg continue
Finishes a multistep operation like graft, histedit, rebase, merge, and unshelve if they are in an interrupted state.
graft copy changes from other branches onto the current branch:
hg graft [OPTION]... [-r REV]... REV...
This command uses Mercurial's merge logic to copy individual changes from other branches without merging branches in the history graph. This is sometimes known as 'backporting' or 'cherry-picking'. By default, graft will copy user, date, and description from the source changesets.
Changesets that are ancestors of the current revision, that have already been grafted, or that are merges will be skipped.
If --log is specified, log messages will have a comment appended of the form:
(grafted from CHANGESETHASH)
If --force is specified, revisions will be grafted even if they are already ancestors of, or have been grafted to, the destination.  This is useful when the revisions have since been backed out.
If a graft merge results in conflicts, the graft process is interrupted so that the current merge can be manually resolved.  Once all conflicts are addressed, the graft process can be continued with the -c/--continue option.
The -c/--continue option reapplies all the earlier options.
The --base option exposes more of how graft internally uses merge with a custom base revision. --base can be used to specify another ancestor than the first and only parent.
hg graft -r 345 --base 234
is thus pretty much the same as:
hg diff --from 234 --to 345 | hg import
but using merge to resolve conflicts and track moved files.
The result of a merge can thus be backported as a single commit by specifying one of the merge parents as base, and thus effectively grafting the changes from the other side.
It is also possible to collapse multiple changesets and clean up history by specifying another ancestor as base, much like rebase --collapse --keep.
The commit message can be tweaked after the fact using commit --amend .
For using non-ancestors as the base to backout changes, see the backout command and the hidden --parent option.
• copy a single change to the stable branch and edit its description:
hg update stable hg graft --edit 9393
• graft a range of changesets with one exception, updating dates:
hg graft -D "2085::2093 and not 2091"
• continue a graft after resolving conflicts:
hg graft -c
• show the source of a grafted changeset:
hg log --debug -r .
• show revisions sorted by date:
hg log -r "sort(all(), date)"
• backport the result of a merge as a single commit:
hg graft -r 123 --base 123^
• land a feature branch as one changeset:
hg up -cr default hg graft -r featureX --base "ancestor('featureX', 'default')"
See hg help revisions for more about specifying revisions.
Returns 0 on successful completion, 1 if there are unresolved files.
-r,--rev <REV[+]> revisions to graft
--base <REV> base revision when doing the graft merge (ADVANCED)
-c, --continue resume interrupted graft
--stop stop interrupted graft
--abort abort interrupted graft
--log  append graft info to log message
--no-commit don't commit, just apply the changes in working directory
-f, --force force graft
-D, --currentdate record the current date as commit date
-U, --currentuser record the current user as committer
merge merge another revision into working directory:
hg merge [-P] [[-r] REV]
The current working directory is updated with all changes made in the requested revision since the last common predecessor revision.
Files that changed between either parent are marked as changed for the next commit and a commit must be performed before any further updates to the repository are allowed. The next commit will have two parents.
--tool can be used to specify the merge tool used for file merges. It overrides the HGMERGE environment variable and your configuration files. See hg help merge-tools for options.
If no revision is specified, the working directory's parent is a head revision, and the current branch contains exactly one other head, the other head is merged with by default. Otherwise, an explicit revision with which to merge must be provided.
See hg help resolve for information on handling file conflicts.
To undo an uncommitted merge, use hg merge --abort which will check out a clean copy of the original merge parent, losing all changes.
Returns 0 on success, 1 if there are unresolved files.
-f, --force force a merge including outstanding changes (DEPRECATED)
-r,--rev <REV> revision to merge
-P, --preview review revisions to merge (no merge is performed)
--abort abort the ongoing merge
Change organization bookmarks create a new bookmark or list existing bookmarks:
hg bookmarks [OPTIONS]... [NAME]...
Bookmarks are labels on changesets to help track lines of development. Bookmarks are unversioned and can be moved, renamed and deleted. Deleting or moving a bookmark has no effect on the associated changesets.
Creating or updating to a bookmark causes it to be marked as 'active'. The active bookmark is indicated with a '*'.  When a commit is made, the active bookmark will advance to the new commit.  A plain hg update will also advance an active bookmark, if possible.  Updating away from a bookmark will cause it to be deactivated.
Bookmarks can be pushed and pulled between repositories (see hg help push and hg help pull). If a shared bookmark has diverged, a new 'divergent bookmark' of the form 'name@path' will be created. Using hg merge will resolve the divergence.
Specifying bookmark as '.' to -m/-d/-l options is equivalent to specifying the active bookmark's name.
A bookmark named '@' has the special property that hg clone will check it out by default if it exists.
The following keywords are supported in addition to the common template keywords and functions such as {bookmark}. See also hg help templates.
active Boolean. True if the bookmark is active.
• create an active bookmark for a new line of development:
hg book new-feature
• create an inactive bookmark as a place marker:
hg book -i reviewed
• create an inactive bookmark on another changeset:
hg book -r .^ tested
• rename bookmark turkey to dinner:
hg book -m turkey dinner
• move the '@' bookmark from another branch:
hg book -f @
• print only the active bookmark name:
hg book -ql .
-f, --force force
-r,--rev <REV> revision for bookmark action
-d, --delete delete a given bookmark
-m,--rename <OLD> rename a given bookmark
-i, --inactive mark a bookmark inactive
-l, --list list existing bookmarks
aliases: bookmark
branch set or show the current branch name:
hg branch [-fC] [NAME]
Note   Branch names are permanent and global. Use hg bookmark to create a light-weight bookmark instead. See hg help glossary for more information about named branches and bookmarks.
With no argument, show the current branch name. With one argument, set the working directory branch name (the branch will not exist in the repository until the next commit). Standard practice recommends that primary development take place on the 'default' branch.
Unless -f/--force is specified, branch will not let you set a branch name that already exists.
Use -C/--clean to reset the working directory branch to that of the parent of the working directory, negating a previous branch change.
Use the command hg update to switch to an existing branch. Use hg commit --close-branch to mark this branch head as closed.  When all heads of a branch are closed, the branch will be considered closed.
-f, --force set branch name even if it shadows an existing branch
-C, --clean reset branch name to parent branch name
-r,--rev <VALUE[+]> change branches of the given revs (EXPERIMENTAL)
branches list repository named branches:
hg branches [-c]
List the repository's named branches, indicating which ones are inactive. If -c/--closed is specified, also list branches which have been marked closed (see hg commit --close-branch).
Use the command hg update to switch to an existing branch.
The following keywords are supported in addition to the common template keywords and functions such as {branch}. See also hg help templates.
active Boolean. True if the branch is active.
closed Boolean. True if the branch is closed.
current Boolean. True if it is the current branch.
Returns 0.
-a, --active show only branches that have unmerged heads (DEPRECATED)
-c, --closed show normal and closed branches
-r,--rev <VALUE[+]> show branch name(s) of the given rev
phase set or show the current phase name:
hg phase [-p|-d|-s] [-f] [-r] [REV...]
With no argument, show the phase name of the current revision(s).
With one of -p/--public, -d/--draft or -s/--secret, change the phase value of the specified revisions.
Unless -f/--force is specified, hg phase won't move changesets from a lower phase to a higher phase. Phases are ordered as follows:
public < draft < secret
Returns 0 on success, 1 if some phases could not be changed.
(For more information about the phases concept, see hg help phases.)
-p, --public set changeset phase to public
-d, --draft set changeset phase to draft
-s, --secret set changeset phase to secret
-f, --force allow to move boundary backward
-r,--rev <REV[+]> target revision
tag add one or more tags for the current or given revision:
hg tag [-f] [-l] [-m TEXT] [-d DATE] [-u USER] [-r REV] NAME...
Name a particular revision using <name>.
Tags are used to name particular revisions of the repository and are very useful to compare different revisions, to go back to significant earlier versions or to mark branch points as releases, etc. Changing an existing tag is normally disallowed; use -f/--force to override.
If no revision is given, the parent of the working directory is used.
To facilitate version control, distribution, and merging of tags, they are stored as a file named ".hgtags" which is managed similarly to other project files and can be hand-edited if necessary. This also means that tagging creates a new commit. The file ".hg/localtags" is used for local tags (not shared among repositories).
Tag commits are usually made at the head of a branch. If the parent of the working directory is not a branch head, hg tag aborts; use -f/--force to force the tag commit to be based on a non-head changeset.
Since tag names have priority over branch names during revision lookup, using an existing branch name as a tag name is discouraged.
-f, --force force tag
-l, --local make the tag local
-r,--rev <REV> revision to tag
--remove remove a tag
tags list repository tags:
hg tags
This lists both regular and local tags. When the -v/--verbose switch is used, a third column "local" is printed for local tags.  When the -q/--quiet switch is used, only the tag name is printed.
The following keywords are supported in addition to the common template keywords and functions such as {tag}. See also hg help templates.
type   String. local for local tags.
File content management annotate show changeset information by line for each file:
hg annotate [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] FILE...
List changes in files, showing the revision id responsible for each line.
This command is useful for discovering when a change was made and by whom.
If you include --file, --user, or --date, the revision number is suppressed unless you also include --number.
Without the -a/--text option, annotate will avoid processing files it detects as binary. With -a, annotate will annotate the file anyway, although the results will probably be neither useful nor desirable.
The following keywords are supported in addition to the common template keywords and functions. See also hg help templates.
lines  List of lines with annotation data.
path   String. Repository-absolute path of the specified file.
And each entry of {lines} provides the following sub-keywords in addition to {date}, {node}, {rev}, {user}, etc.
line   String. Line content.
lineno Integer. Line number at that revision.
path   String. Repository-absolute path of the file at that revision.
See hg help templates.operators for the list expansion syntax.
-r,--rev <REV> annotate the specified revision
--follow follow copies/renames and list the filename (DEPRECATED)
--no-follow don't follow copies and renames
-u, --user list the author (long with -v)
-f, --file list the filename
-d, --date list the date (short with -q)
-n, --number list the revision number (default)
-c, --changeset list the changeset
-l, --line-number show line number at the first appearance
--skip <REV[+]> revset to not display (EXPERIMENTAL)
-w, --ignore-all-space ignore white space when comparing lines
-Z, --ignore-space-at-eol ignore changes in whitespace at EOL
aliases: blame
cat output the current or given revision of files:
hg cat [OPTION]... FILE...
Print the specified files as they were at the given revision. If no revision is given, the parent of the working directory is used.
Output may be to a file, in which case the name of the file is given using a template string. See hg help templates. In addition to the common template keywords, the following formatting rules are supported:
literal "%" character
basename of file being printed
dirname of file being printed, or '.' if in repository root
root-relative path name of file being printed
%H
changeset hash (40 hexadecimal digits)
%R
changeset revision number
%h
short-form changeset hash (12 hexadecimal digits)
zero-padded changeset revision number
basename of the exporting repository
literal "" character
data   String. File content.
path   String. Repository-absolute path of the file.
-o,--output <FORMAT> print output to file with formatted name
-r,--rev <REV> print the given revision
--decode apply any matching decode filter
copy mark files as copied for the next commit:
hg copy [OPTION]... (SOURCE... DEST | --forget DEST...)
Mark dest as having copies of source files. If dest is a directory, copies are put in that directory. If dest is a file, the source must be a single file.
By default, this command copies the contents of files as they exist in the working directory. If invoked with -A/--after, the operation is recorded, but no copying is performed.
To undo marking a destination file as copied, use --forget. With that option, all given (positional) arguments are unmarked as copies. The destination file(s) will be left in place (still tracked). Note that hg copy --forget behaves the same way as hg rename --forget.
This command takes effect with the next commit by default.
Returns 0 on success, 1 if errors are encountered.
--forget unmark a destination file as copied
-A, --after record a copy that has already occurred
--at-rev <REV> (un)mark copies in the given revision (EXPERIMENTAL)
-f, --force forcibly copy over an existing managed file
aliases: cp
diff diff repository (or selected files):
hg diff [OPTION]... ([-c REV] | [--from REV1] [--to REV2]) [FILE]...
Show differences between revisions for the specified files.
Differences between files are shown using the unified diff format.
Note   hg diff may generate unexpected results for merges, as it will default to comparing against the working directory's first parent changeset if no revisions are specified.
By default, the working directory files are compared to its first parent. To see the differences from another revision, use --from. To see the difference to another revision, use --to. For example, hg diff --from .^ will show the differences from the working copy's grandparent to the working copy, hg diff --to . will show the diff from the working copy to its parent (i.e. the reverse of the default), and hg diff --from 1.0 --to 1.2 will show the diff between those two revisions.
Alternatively you can specify -c/--change with a revision to see the changes in that changeset relative to its first parent (i.e. hg diff -c 42 is equivalent to hg diff --from 42^ --to 42)
Without the -a/--text option, diff will avoid generating diffs of files it detects as binary. With -a, diff will generate a diff anyway, probably with undesirable results.
Use the -g/--git option to generate diffs in the git extended diff format. For more information, read hg help diffs.
• compare a file in the current working directory to its parent:
hg diff foo.c
• compare two historical versions of a directory, with rename info:
hg diff --git --from 1.0 --to 1.2 lib/
• get change stats relative to the last change on some date:
hg diff --stat --from "date('may 2')"
• diff all newly-added files that contain a keyword:
hg diff "set:added() and grep(GNU)"
• compare a revision and its parents:
hg diff -c 9353                  # compare against first parent hg diff --from 9353^ --to 9353   # same using revset syntax hg diff --from 9353^2 --to 9353  # compare against the second parent
-r,--rev <REV[+]> revision (DEPRECATED)
--from <REV1> revision to diff from
--to <REV2> revision to diff to
-c,--change <REV> change made by revision
-g, --git use git extended diff format (DEFAULT: diff.git)
--binary generate binary diffs in git mode (default)
--nodates omit dates from diff headers
--noprefix omit a/ and b/ prefixes from filenames
-p, --show-function show which function each change is in (DEFAULT: diff.showfunc)
--reverse produce a diff that undoes the changes
-U,--unified <NUM> number of lines of context to show
--root <DIR> produce diffs relative to subdirectory
grep search for a pattern in specified files:
hg grep [--diff] [OPTION]... PATTERN [FILE]...
Search the working directory or revision history for a regular expression in the specified files for the entire repository.
By default, grep searches the repository files in the working directory and prints the files where it finds a match. To specify historical revisions instead of the working directory, use the --rev flag.
To search instead historical revision differences that contains a change in match status ("-" for a match that becomes a non-match, or "+" for a non-match that becomes a match), use the --diff flag.
PATTERN can be any Python (roughly Perl-compatible) regular expression.
If no FILEs are specified and the --rev flag isn't supplied, all files in the working directory are searched. When using the --rev flag and specifying FILEs, use the --follow argument to also follow the specified FILEs across renames and copies.
change String. Character denoting insertion + or removal -.  Available if --diff is specified.
lineno Integer. Line number of the match.
texts  List of text chunks.
And each entry of {texts} provides the following sub-keywords.
matched Boolean. True if the chunk matches the specified pattern.
text   String. Chunk content.
Returns 0 if a match is found, 1 otherwise.
-0, --print0 end fields with NUL
--all  an alias to --diff (DEPRECATED)
--diff search revision differences for when the pattern was added or removed
-f, --follow follow changeset history, or file history across copies and renames
-i, --ignore-case ignore case when matching
-l, --files-with-matches print only filenames and revisions that match
-n, --line-number print matching line numbers
-r,--rev <REV[+]> search files changed within revision range
--all-files include all files in the changeset while grepping (DEPRECATED)
Change navigation bisect subdivision search of changesets:
hg bisect [-gbsr] [-U] [-c CMD] [REV]
This command helps to find changesets which introduce problems. To use, mark the earliest changeset you know exhibits the problem as bad, then mark the latest changeset which is free from the problem as good. Bisect will update your working directory to a revision for testing (unless the -U/--noupdate option is specified). Once you have performed tests, mark the working directory as good or bad, and bisect will either update to another candidate changeset or announce that it has found the bad revision.
As a shortcut, you can also use the revision argument to mark a revision as good or bad without checking it out first.
If you supply a command, it will be used for automatic bisection.  The environment variable HG_NODE will contain the ID of the changeset being tested. The exit status of the command will be used to mark revisions as good or bad: status 0 means good, 125 means to skip the revision, 127 (command not found) will abort the bisection, and any other non-zero exit status means the revision is bad.
• start a bisection with known bad revision 34, and good revision 12:
hg bisect --bad 34 hg bisect --good 12
• advance the current bisection by marking current revision as good or bad:
hg bisect --good hg bisect --bad
• mark the current revision, or a known revision, to be skipped (e.g. if that revision is not usable because of another issue):
hg bisect --skip hg bisect --skip 23
• skip all revisions that do not touch directories foo or bar:
hg bisect --skip "!( file('path:foo') & file('path:bar') )"
• forget the current bisection:
hg bisect --reset
• use 'make && make tests' to automatically find the first broken revision:
hg bisect --reset hg bisect --bad 34 hg bisect --good 12 hg bisect --command "make && make tests"
• see all changesets whose states are already known in the current bisection:
hg log -r "bisect(pruned)"
• see the changeset currently being bisected (especially useful if running with -U/--noupdate):
hg log -r "bisect(current)"
• see all changesets that took part in the current bisection:
hg log -r "bisect(range)"
• you can even get a nice graph:
hg log --graph -r "bisect(range)"
See hg help revisions.bisect for more about the bisect() predicate.
-r, --reset reset bisect state
-g, --good mark changeset good
-b, --bad mark changeset bad
-s, --skip skip testing changeset
-e, --extend extend the bisect range
-c,--command <CMD> use command to check changeset state
-U, --noupdate do not update to target
heads show branch heads:
hg heads [-ct] [-r STARTREV] [REV]...
With no arguments, show all open branch heads in the repository.  Branch heads are changesets that have no descendants on the same branch. They are where development generally takes place and are the usual targets for update and merge operations.
If one or more REVs are given, only open branch heads on the branches associated with the specified changesets are shown. This means that you can use hg heads . to see the heads on the currently checked-out branch.
If -c/--closed is specified, also show branch heads marked closed (see hg commit --close-branch).
If STARTREV is specified, only those heads that are descendants of STARTREV will be displayed.
If -t/--topo is specified, named branch mechanics will be ignored and only topological heads (changesets with no children) will be shown.
Returns 0 if matching heads are found, 1 if not.
-r,--rev <STARTREV> show only heads which are descendants of STARTREV
-t, --topo show topological heads only
-a, --active show active branchheads only (DEPRECATED)
-c, --closed show normal and closed branch heads
identify identify the working directory or specified revision:
hg identify [-nibtB] [-r REV] [SOURCE]
Print a summary identifying the repository state at REV using one or two parent hash identifiers, followed by a "+" if the working directory has uncommitted changes, the branch name (if not default), a list of tags, and a list of bookmarks.
When REV is not given, print a summary of the current state of the repository including the working directory. Specify -r. to get information of the working directory parent without scanning uncommitted changes.
Specifying a path to a repository root or Mercurial bundle will cause lookup to operate on that repository/bundle.
dirty  String. Character + denoting if the working directory has uncommitted changes.
id     String. One or two nodes, optionally followed by +.
parents List of strings. Parent nodes of the changeset.
• generate a build identifier for the working directory:
hg id --id > build-id.dat
• find the revision corresponding to a tag:
hg id -n -r 1.3
• check the most recent revision of a remote repository:
hg id -r tip https://www.mercurial-scm.org/repo/hg/
See hg log for generating more information about specific revisions, including full hash identifiers.
Returns 0 if successful.
-r,--rev <REV> identify the specified revision
-n, --num show local revision number
-i, --id show global revision id
-b, --branch show branch
-t, --tags show tags
-B, --bookmarks show bookmarks
aliases: id
log show revision history of entire repository or files:
hg log [OPTION]... [FILE]
Print the revision history of the specified files or the entire project.
If no revision range is specified, the default is tip:0 unless --follow is set.
File history is shown without following rename or copy history of files. Use -f/--follow with a filename to follow history across renames and copies. --follow without a filename will only show ancestors of the starting revisions. The starting revisions can be specified by -r/--rev, which default to the working directory parent.
By default this command prints revision number and changeset id, tags, non-trivial parents, user, date and time, and a summary for each commit. When the -v/--verbose switch is used, the list of changed files and full commit message are shown.
With --graph the revisions are shown as an ASCII art DAG with the most recent changeset at the top.  'o' is a changeset, '@' is a working directory parent, '%' is a changeset involved in an unresolved merge conflict, '_' closes a branch, 'x' is obsolete, '*' is unstable, and '+' represents a fork where the changeset from the lines below is a parent of the 'o' merge on the same line.  Paths in the DAG are represented with '|', '/' and so forth. ':' in place of a '|' indicates one or more revisions in a path are omitted.
Use -L/--line-range FILE,M:N options to follow the history of lines from M to N in FILE. With -p/--patch only diff hunks affecting specified line range will be shown. This option requires --follow; it can be specified multiple times. Currently, this option is not compatible with --graph. This option is experimental.
Note   hg log --patch may generate unexpected diff output for merge changesets, as it will only compare the merge changeset against its first parent. Also, only files different from BOTH parents will appear in files:.
Note   For performance reasons, hg log FILE may omit duplicate changes made on branches and will not show removals or mode changes. To see all such changes, use the --removed switch.
Note   The history resulting from -L/--line-range options depends on diff options; for instance if white-spaces are ignored, respective changes with only white-spaces in specified line range will not be listed.
• changesets with full descriptions and file lists:
hg log -v
• changesets ancestral to the working directory:
hg log -f
• last 10 commits on the current branch:
hg log -l 10 -b .
• changesets showing all modifications of a file, including removals:
hg log --removed file.c
• all changesets that touch a directory, with diffs, excluding merges:
hg log -Mp lib/
• all revision numbers that match a keyword:
hg log -k bug --template "{rev}\n"
• the full hash identifier of the working directory parent:
hg log -r . --template "{node}\n"
• list available log templates:
hg log -T list
• check if a given changeset is included in a tagged release:
hg log -r "a21ccf and ancestor(1.9)"
• find all changesets by some user in a date range:
hg log -k alice -d "may 2008 to jul 2008"
• summary of all changesets after the last tag:
hg log -r "last(tagged())::" --template "{desc|firstline}\n"
• changesets touching lines 13 to 23 for file.c:
hg log -L file.c,13:23
• changesets touching lines 13 to 23 for file.c and lines 2 to 6 of main.c with patch:
hg log -L file.c,13:23 -L main.c,2:6 -p
See hg help revisions for more about specifying and ordering revisions.
See hg help templates for more about pre-packaged styles and specifying custom templates. The default template used by the log command can be customized via the command-templates.log configuration setting.
--follow-first only follow the first parent of merge changesets (DEPRECATED)
-d,--date <DATE> show revisions matching date spec
-C, --copies show copied files
-k,--keyword <TEXT[+]> do case-insensitive search for a given text
-r,--rev <REV[+]> revisions to select or follow from
-L,--line-range <FILE,RANGE[+]> follow line range of specified file (EXPERIMENTAL)
--removed include revisions where files were removed
-m, --only-merges show only merges (DEPRECATED) (use -r "merge()" instead)
-u,--user <USER[+]> revisions committed by user
--only-branch <BRANCH[+]> show only changesets within the given named branch (DEPRECATED)
-b,--branch <BRANCH[+]> show changesets within the given named branch
-B,--bookmark <BOOKMARK[+]> show changesets within the given bookmark
-P,--prune <REV[+]> do not display revision or any of its ancestors
aliases: history
parents show the parents of the working directory or revision (DEPRECATED):
hg parents [-r REV] [FILE]
Print the working directory's parent revisions. If a revision is given via -r/--rev, the parent of that revision will be printed.  If a file argument is given, the revision in which the file was last changed (before the working directory revision or the argument to --rev if given) is printed.
This command is equivalent to:
hg log -r "p1()+p2()" or hg log -r "p1(REV)+p2(REV)" or hg log -r "max(::p1() and file(FILE))+max(::p2() and file(FILE))" or hg log -r "max(::p1(REV) and file(FILE))+max(::p2(REV) and file(FILE))"
See hg summary and hg help revsets for related information.
-r,--rev <REV> show parents of the specified revision
tip show the tip revision (DEPRECATED):
hg tip [-p] [-g]
The tip revision (usually just called the tip) is the changeset most recently added to the repository (and therefore the most recently changed head).
If you have just made a commit, that commit will be the tip. If you have just pulled changes from another repository, the tip of that repository becomes the current tip. The "tip" tag is special and cannot be renamed or assigned to a different changeset.
This command is deprecated, please use hg heads instead.
Working directory management add add the specified files on the next commit: