neulab/tldr huggingface dataset:
hg add [OPTION]... [FILE]...
Schedule files to be version controlled and added to the repository.
The files will be added to the repository at the next commit. To undo an add before that, see hg forget.
If no names are given, add all files to the repository (except files matching .hgignore).
• New (unknown) files are added automatically by hg add:
$ ls foo.c $ hg status ? foo.c $ hg add adding foo.c $ hg status A foo.c
• Specific files to be added can be specified:
$ ls bar.c  foo.c $ hg status ? bar.c ? foo.c $ hg add bar.c $ hg status A bar.c ? foo.c
Returns 0 if all files are successfully added.
addremove add all new files, delete all missing files:
hg addremove [OPTION]... [FILE]...
Add all new files and remove all missing files from the repository.
Unless names are given, new files are ignored if they match any of the patterns in .hgignore. As with add, these changes take effect at the next commit.
Use the -s/--similarity option to detect renamed files. This option takes a percentage between 0 (disabled) and 100 (files must be identical) as its parameter. With a parameter greater than 0, this compares every removed file with every added file and records those similar enough as renames. Detecting renamed files this way can be expensive. After using this option, hg status -C can be used to check which files were identified as moved or renamed. If not specified, -s/--similarity defaults to 100 and only renames of identical files are detected.
• A number of files (bar.c and foo.c) are new, while foobar.c has been removed (without using hg remove) from the repository:
$ ls bar.c foo.c $ hg status ! foobar.c ? bar.c ? foo.c $ hg addremove adding bar.c adding foo.c removing foobar.c $ hg status A bar.c A foo.c R foobar.c
• A file foobar.c was moved to foo.c without using hg rename. Afterwards, it was edited slightly:
$ ls foo.c $ hg status ! foobar.c ? foo.c $ hg addremove --similarity 90 removing foobar.c adding foo.c recording removal of foobar.c as rename to foo.c (94% similar) $ hg status -C A foo.c foobar.c R foobar.c
-s,--similarity <SIMILARITY> guess renamed files by similarity (0<=s<=100)
files list tracked files:
hg files [OPTION]... [FILE]...
Print files under Mercurial control in the working directory or specified revision for given files (excluding removed files).  Files can be specified as filenames or filesets.
If no files are given to match, this command prints the names of all files under Mercurial control.
flags  String. Character denoting file's symlink and executable bits.
size   Integer. Size of the file in bytes.
• list all files under the current directory:
hg files .
• shows sizes and flags for current revision:
hg files -vr .
• list all files named README:
hg files -I "**/README"
• list all binary files:
hg files "set:binary()"
• find files containing a regular expression:
hg files "set:grep('bob')"
• search tracked file contents with xargs and grep:
hg files -0 | xargs -0 grep foo
See hg help patterns and hg help filesets for more information on specifying file patterns.
-r,--rev <REV> search the repository as it is in REV
-0, --print0 end filenames with NUL, for use with xargs
forget forget the specified files on the next commit:
hg forget [OPTION]... FILE...
Mark the specified files so they will no longer be tracked after the next commit.
This only removes files from the current branch, not from the entire project history, and it does not delete them from the working directory.
To delete the file from the working directory, see hg remove.
To undo a forget before the next commit, see hg add.
• forget newly-added binary files:
hg forget "set:added() and binary()"
• forget files that would be excluded by .hgignore:
hg forget "set:hgignore()"
locate locate files matching specific patterns (DEPRECATED):
hg locate [OPTION]... [PATTERN]...
Print files under Mercurial control in the working directory whose names match the given patterns.
By default, this command searches all directories in the working directory. To search just the current directory and its subdirectories, use "--include .".
If no patterns are given to match, this command prints the names of all files under Mercurial control in the working directory.
If you want to feed the output of this command into the "xargs" command, use the -0 option to both this command and "xargs". This will avoid the problem of "xargs" treating single filenames that contain whitespace as multiple filenames.
See hg help files for a more versatile command.
-f, --fullpath print complete paths from the filesystem root
purge removes files not tracked by Mercurial:
hg purge [OPTION]... [DIR]...
Delete files not known to Mercurial. This is useful to test local and uncommitted changes in an otherwise-clean source tree.
This means that purge will delete the following by default:
• Unknown files: files marked with "?" by hg status
• Empty directories: in fact Mercurial ignores directories unless they contain files under source control management
But it will leave untouched:
• Modified and unmodified tracked files
• Ignored files (unless -i or --all is specified)
• New files added to the repository (with hg add)
The --files and --dirs options can be used to direct purge to delete only files, only directories, or both. If neither option is given, both will be deleted.
If directories are given on the command line, only files in these directories are considered.
Be careful with purge, as you could irreversibly delete some files you forgot to add to the repository. If you only want to print the list of files that this program would delete, use the --print option.
-a, --abort-on-err abort if an error occurs
--all  purge ignored files too
-i, --ignored purge only ignored files
--dirs purge empty directories
--files purge files
-p, --print print filenames instead of deleting them
-0, --print0 end filenames with NUL, for use with xargs (implies -p/--print)
--confirm ask before permanently deleting files
aliases: clean
remove remove the specified files on the next commit:
hg remove [OPTION]... FILE...
Schedule the indicated files for removal from the current branch.
This command schedules the files to be removed at the next commit.  To undo a remove before that, see hg revert. To undo added files, see hg forget.
-A/--after can be used to remove only files that have already been deleted, -f/--force can be used to force deletion, and -Af can be used to remove files from the next revision without deleting them from the working directory.
The following table details the behavior of remove for different file states (columns) and option combinations (rows). The file states are Added [A], Clean [C], Modified [M] and Missing [!]  (as reported by hg status). The actions are Warn, Remove (from branch) and Delete (from disk):
┌──────────┬───┬────┬────┬───┐ │opt/state │ A │ C  │ M  │ ! │ ├──────────┼───┼────┼────┼───┤ │none      │ W │ RD │ W  │ R │ └──────────┴───┴────┴────┴───┘
│-f        │ R │ RD │ RD │ R │ ├──────────┼───┼────┼────┼───┤ │-A        │ W │ W  │ W  │ R │ ├──────────┼───┼────┼────┼───┤ │-Af       │ R │ R  │ R  │ R │ └──────────┴───┴────┴────┴───┘
Note   hg remove never deletes files in Added [A] state from the working directory, not even if --force is specified.
Returns 0 on success, 1 if any warnings encountered.
-A, --after record delete for missing files
-f, --force forget added files, delete modified files
aliases: rm
rename rename files; equivalent of copy + remove:
hg rename [OPTION]... SOURCE... DEST
Mark dest as copies of sources; mark sources for deletion. If dest is a directory, copies are put in that directory. If dest is a file, there can only be one source.
To undo marking a destination file as renamed, use --forget. With that option, all given (positional) arguments are unmarked as renames. The destination file(s) will be left in place (still tracked). The source file(s) will not be restored. Note that hg rename --forget behaves the same way as hg copy --forget.
--forget unmark a destination file as renamed
-A, --after record a rename that has already occurred
--at-rev <REV> (un)mark renames in the given revision (EXPERIMENTAL)
-f, --force forcibly move over an existing managed file
aliases: move mv
resolve redo merges or set/view the merge status of files:
hg resolve [OPTION]... [FILE]...
Merges with unresolved conflicts are often the result of non-interactive merging using the internal:merge configuration setting, or a command-line merge tool like diff3. The resolve command is used to manage the files involved in a merge, after hg merge has been run, and before hg commit is run (i.e. the working directory must have two parents). See hg help merge-tools for information on configuring merge tools.
The resolve command can be used in the following ways:
• hg resolve [--re-merge] [--tool TOOL] FILE...: attempt to re-merge the specified files, discarding any previous merge attempts. Re-merging is not performed for files already marked as resolved. Use --all/-a to select all unresolved files. --tool can be used to specify the merge tool used for the given files. It overrides the HGMERGE environment variable and your configuration files.  Previous file contents are saved with a .orig suffix.
• hg resolve -m [FILE]: mark a file as having been resolved (e.g. after having manually fixed-up the files). The default is to mark all unresolved files.
• hg resolve -u [FILE]...: mark a file as unresolved. The default is to mark all resolved files.
• hg resolve -l: list files which had or still have conflicts.  In the printed list, U = unresolved and R = resolved.  You can use set:unresolved() or set:resolved() to filter the list. See hg help filesets for details.
Note   Mercurial will not let you commit files with unresolved merge conflicts. You must use hg resolve -m ... before you can commit after a conflicting merge.
mergestatus String. Character denoting merge conflicts, U or R.
Returns 0 on success, 1 if any files fail a resolve attempt.
-a, --all select all unresolved files
-l, --list list state of files needing merge
-m, --mark mark files as resolved
-u, --unmark mark files as unresolved
-n, --no-status hide status prefix
--re-merge re-merge files
revert restore files to their checkout state:
hg revert [OPTION]... [-r REV] [NAME]...
Note   To check out earlier revisions, you should use hg update REV.  To cancel an uncommitted merge (and lose your changes), use hg merge --abort.
With no revision specified, revert the specified files or directories to the contents they had in the parent of the working directory.  This restores the contents of files to an unmodified state and unschedules adds, removes, copies, and renames. If the working directory has two parents, you must explicitly specify a revision.
Using the -r/--rev or -d/--date options, revert the given files or directories to their states as of a specific revision. Because revert does not change the working directory parents, this will cause these files to appear modified. This can be helpful to "back out" some or all of an earlier change. See hg backout for a related method.
Modified files are saved with a .orig suffix before reverting.  To disable these backups, use --no-backup. It is possible to store the backup files in a custom directory relative to the root of the repository by setting the ui.origbackuppath configuration option.
See hg help backout for a way to reverse the effect of an earlier changeset.
-a, --all revert all changes when no arguments given
-d,--date <DATE> tipmost revision matching date
-r,--rev <REV> revert to the specified revision
-C, --no-backup do not save backup copies of files
-i, --interactive interactively select the changes
root print the root (top) of the current working directory:
hg root
Print the root directory of the current repository.
hgpath String. Path to the .hg directory.
storepath String. Path to the directory holding versioned data.
shelve save and set aside changes from the working directory:
hg shelve [OPTION]... [FILE]...
Shelving takes files that "hg status" reports as not clean, saves the modifications to a bundle (a shelved change), and reverts the files so that their state in the working directory becomes clean.
To restore these changes to the working directory, using "hg unshelve"; this will work even if you switch to a different commit.
When no files are specified, "hg shelve" saves all not-clean files. If specific files or directories are named, only changes to those files are shelved.
In bare shelve (when no files are specified, without interactive, include and exclude option), shelving remembers information if the working directory was on newly created branch, in other words working directory was on different branch than its first parent. In this situation unshelving restores branch information to the working directory.
Each shelved change has a name that makes it easier to find later.  The name of a shelved change defaults to being based on the active bookmark, or if there is no active bookmark, the current named branch.  To specify a different name, use --name.
To see a list of existing shelved changes, use the --list option. For each shelved change, this will print its name, age, and description; use --patch or --stat for more details.
To delete specific shelved changes, use --delete. To delete all shelved changes, use --cleanup.
-A, --addremove mark new/missing files as added/removed before shelving
-u, --unknown store unknown files in the shelve
--cleanup delete all shelved changes
--date <DATE> shelve with the specified commit date
-d, --delete delete the named shelved change(s)
-k, --keep shelve, but keep changes in the working directory
-l, --list list current shelves
-m,--message <TEXT> use text as shelve message
-n,--name <NAME> use the given name for the shelved commit
-p, --patch output patches for changes (provide the names of the shelved changes as positional arguments)
-i, --interactive interactive mode
--stat output diffstat-style summary of changes (provide the names of the shelved changes as positional arguments)
status show changed files in the working directory:
hg status [OPTION]... [FILE]...
Show status of files in the repository. If names are given, only files that match are shown. Files that are clean or ignored or the source of a copy/move operation, are not listed unless -c/--clean, -i/--ignored, -C/--copies or -A/--all are given.  Unless options described with "show only ..." are given, the options -mardu are used.
Option -q/--quiet hides untracked (unknown and ignored) files unless explicitly requested with -u/--unknown or -i/--ignored.
Note   hg status may appear to disagree with diff if permissions have changed or a merge has occurred. The standard diff format does not report permission changes and diff only reports changes relative to one merge parent.
If one revision is given, it is used as the base revision.  If two revisions are given, the differences between them are shown. The --change option can also be used as a shortcut to list the changed files of a revision from its first parent.
The codes used to show the status of files are:
M = modified A = added R = removed C = clean ! = missing (deleted by non-hg command, but still tracked) ? = not tracked I = ignored = origin of the previous file (with --copies)
The -t/--terse option abbreviates the output by showing only the directory name if all the files in it share the same status. The option takes an argument indicating the statuses to abbreviate: 'm' for 'modified', 'a' for 'added', 'r' for 'removed', 'd' for 'deleted', 'u' for 'unknown', 'i' for 'ignored' and 'c' for clean.
It abbreviates only those statuses which are passed. Note that clean and ignored files are not displayed with '--terse ic' unless the -c/--clean and -i/--ignored options are also used.
The -v/--verbose option shows information when the repository is in an unfinished merge, shelve, rebase state etc. You can have this behavior turned on by default by enabling the commands.status.verbose option.
You can skip displaying some of these states by setting commands.status.skipstates to one or more of: 'bisect', 'graft', 'histedit', 'merge', 'rebase', or 'unshelve'.
source String. Repository-absolute path of the file originated from. Available if --copies is specified.
status String. Character denoting file's status.
• show changes in the working directory relative to a changeset:
hg status --rev 9353
• show changes in the working directory relative to the current directory (see hg help patterns for more information):
hg status re:
• show all changes including copies in an existing changeset:
hg status --copies --change 9353
• get a NUL separated list of added files, suitable for xargs:
hg status -an0
• show more information about the repository status, abbreviating added, removed, modified, deleted, and untracked paths:
hg status -v -t mardu
-A, --all show status of all files
-m, --modified show only modified files
-a, --added show only added files
-r, --removed show only removed files
-d, --deleted show only missing files
-c, --clean show only files without changes
-u, --unknown show only unknown (not tracked) files
-i, --ignored show only ignored files
-t,--terse <VALUE> show the terse output (EXPERIMENTAL) (default: nothing)
-C, --copies show source of copied files (DEFAULT: ui.statuscopies)
--rev <REV[+]> show difference from revision
--change <REV> list the changed files of a revision
aliases: st
summary summarize working directory state:
hg summary [--remote]
This generates a brief summary of the working directory state, including parents, branch, commit status, phase and available updates.
With the --remote option, this will check the default paths for incoming and outgoing changes. This can be time-consuming.
--remote check for push and pull
aliases: sum
unshelve restore a shelved change to the working directory:
hg unshelve [OPTION]... [[-n] SHELVED]
This command accepts an optional name of a shelved change to restore. If none is given, the most recent shelved change is used.
If a shelved change is applied successfully, the bundle that contains the shelved changes is moved to a backup location (.hg/shelve-backup).
Since you can restore a shelved change on top of an arbitrary commit, it is possible that unshelving will result in a conflict between your changes and the commits you are unshelving onto. If this occurs, you must resolve the conflict, then use --continue to complete the unshelve operation. (The bundle will not be moved until you successfully complete the unshelve.)
(Alternatively, you can use --abort to abandon an unshelve that causes a conflict. This reverts the unshelved changes, and leaves the bundle in place.)
If bare shelved change (without interactive, include and exclude option) was done on newly created branch it would restore branch information to the working directory.
After a successful unshelve, the shelved changes are stored in a backup directory. Only the N most recent backups are kept. N defaults to 10 but can be overridden using the shelve.maxbackups configuration option.
Timestamp in seconds is used to decide order of backups. More than maxbackups backups are kept, if same timestamp prevents from deciding exact order of them, for safety.
Selected changes can be unshelved with --interactive flag.  The working directory is updated with the selected changes, and only the unselected changes remain shelved.  Note: The whole shelve is applied to working directory first before running interactively. So, this will bring up all the conflicts between working directory and the shelve, irrespective of which changes will be unshelved.
-a, --abort abort an incomplete unshelve operation
-c, --continue continue an incomplete unshelve operation
-i, --interactive use interactive mode (EXPERIMENTAL)
-k, --keep keep shelve after unshelving
-n,--name <NAME> restore shelved change with given name
-t,--tool <VALUE> specify merge tool
--date <DATE> set date for temporary commits (DEPRECATED)
update update working directory (or switch revisions):
hg update [-C|-c|-m] [-d DATE] [[-r] REV]
Update the repository's working directory to the specified changeset. If no changeset is specified, update to the tip of the current named branch and move the active bookmark (see hg help bookmarks).
Update sets the working directory's parent revision to the specified changeset (see hg help parents).
If the changeset is not a descendant or ancestor of the working directory's parent and there are uncommitted changes, the update is aborted. With the -c/--check option, the working directory is checked for uncommitted changes; if none are found, the working directory is updated to the specified changeset.
The -C/--clean, -c/--check, and -m/--merge options control what happens if the working directory contains uncommitted changes.  At most of one of them can be specified.
1. If no option is specified, and if the requested changeset is an ancestor or descendant of the working directory's parent, the uncommitted changes are merged into the requested changeset and the merged result is left uncommitted. If the requested changeset is not an ancestor or descendant (that is, it is on another branch), the update is aborted and the uncommitted changes are preserved.
2. With the -m/--merge option, the update is allowed even if the requested changeset is not an ancestor or descendant of the working directory's parent.
3. With the -c/--check option, the update is aborted and the uncommitted changes are preserved.
4. With the -C/--clean option, uncommitted changes are discarded and the working directory is updated to the requested changeset.
To cancel an uncommitted merge (and lose your changes), use hg merge --abort.
Use null as the changeset to remove the working directory (like hg clone -U).
If you want to revert just one file to an older revision, use hg revert [-r REV] NAME.
-C, --clean discard uncommitted changes (no backup)
-c, --check require clean working directory
-m, --merge merge uncommitted changes
-r,--rev <REV> revision
aliases: up checkout co
Change import/export archive create an unversioned archive of a repository revision:
hg archive [OPTION]... DEST
By default, the revision used is the parent of the working directory; use -r/--rev to specify a different revision.
The archive type is automatically detected based on file extension (to override, use -t/--type).
• create a zip file containing the 1.0 release:
hg archive -r 1.0 project-1.0.zip
• create a tarball excluding .hg files:
hg archive project.tar.gz -X ".hg*"
Valid types are:
a directory full of files (default)
tar archive, uncompressed
tbz2
tar archive, compressed using bzip2
tar archive, compressed using gzip
txz
tar archive, compressed using lzma (only in Python 3)
uzip
zip archive, uncompressed
zip archive, compressed using deflate
The exact name of the destination archive or directory is given using a format string; see hg help export for details.
Each member added to an archive file has a directory prefix prepended. Use -p/--prefix to specify a format string for the prefix. The default is the basename of the archive, with suffixes removed.
--no-decode do not pass files through decoders
-p,--prefix <PREFIX> directory prefix for files in archive
-r,--rev <REV> revision to distribute
-t,--type <TYPE> type of distribution to create
bundle create a bundle file:
hg bundle [-f] [-t BUNDLESPEC] [-a] [-r REV]... [--base REV]... FILE [DEST]...
Generate a bundle file containing data to be transferred to another repository.
To create a bundle containing all changesets, use -a/--all (or --base null). Otherwise, hg assumes the destination will have all the nodes you specify with --base parameters. Otherwise, hg will assume the repository has all the nodes in destination, or default-push/default if no destination is specified, where destination is the repositories you provide through DEST option.
You can change bundle format with the -t/--type option. See hg help bundlespec for documentation on this format. By default, the most appropriate format is used and compression defaults to bzip2.
The bundle file can then be transferred using conventional means and applied to another repository with the unbundle or pull command. This is useful when direct push and pull are not available or when exporting an entire repository is undesirable.
Applying bundles preserves all changeset contents including permissions, copy/rename information, and revision history.
Returns 0 on success, 1 if no changes found.
-r,--rev <REV[+]> a changeset intended to be added to the destination
-b,--branch <BRANCH[+]> a specific branch you would like to bundle
--base <REV[+]> a base changeset assumed to be available at the destination
-a, --all bundle all changesets in the repository
-t,--type <TYPE> bundle compression type to use (default: bzip2)
export dump the header and diffs for one or more changesets:
hg export [OPTION]... [-o OUTFILESPEC] [-r] [REV]...
Print the changeset header and diffs for one or more revisions.  If no revision is given, the parent of the working directory is used.
The information shown in the changeset header is: author, date, branch name (if non-default), changeset hash, parent(s) and commit comment.
Note   hg export may generate unexpected diff output for merge changesets, as it will compare the merge changeset against its first parent only.
%N
number of patches being generated
first line of the commit message (only alphanumeric characters)
%n
zero-padded sequence number, starting at 1
Without the -a/--text option, export will avoid generating diffs of files it detects as binary. With -a, export will generate a diff anyway, probably with undesirable results.
With -B/--bookmark changesets reachable by the given bookmark are selected.
Use the -g/--git option to generate diffs in the git extended diff format. See hg help diffs for more information.
With the --switch-parent option, the diff will be against the second parent. It can be useful to review a merge.
diff   String. Diff content.
• use export and import to transplant a bugfix to the current branch:
hg export -r 9353 | hg import -
• export all the changesets between two revisions to a file with rename information:
hg export --git -r 123:150 > changes.txt
• split outgoing changes into a series of patches with descriptive names:
hg export -r "outgoing()" -o "%n-%m.patch"
-B,--bookmark <BOOKMARK> export changes only reachable by given bookmark
--switch-parent diff against the second parent
-r,--rev <REV[+]> revisions to export
import import an ordered set of patches:
hg import [OPTION]... PATCH...
Import a list of patches and commit them individually (unless --no-commit is specified).
To read a patch from standard input (stdin), use "-" as the patch name. If a URL is specified, the patch will be downloaded from there.
Import first applies changes to the working directory (unless --bypass is specified), import will abort if there are outstanding changes.
Use --bypass to apply and commit patches directly to the repository, without affecting the working directory. Without --exact, patches will be applied on top of the working directory parent revision.
You can import a patch straight from a mail message. Even patches as attachments work (to use the body part, it must have type text/plain or text/x-patch). From and Subject headers of email message are used as default committer and commit message. All text/plain body parts before first diff are added to the commit message.
If the imported patch was generated by hg export, user and description from patch override values from message headers and body. Values given on command line with -m/--message and -u/--user override these.
If --exact is specified, import will set the working directory to the parent of each patch before applying it, and will abort if the resulting changeset has a different ID than the one recorded in the patch. This will guard against various ways that portable patch formats and mail systems might fail to transfer Mercurial data or metadata. See hg bundle for lossless transmission.
Use --partial to ensure a changeset will be created from the patch even if some hunks fail to apply. Hunks that fail to apply will be written to a <target-file>.rej file. Conflicts can then be resolved by hand before hg commit --amend is run to update the created changeset. This flag exists to let people import patches that partially apply without losing the associated metadata (author, date, description, ...).
Note   When no hunks apply cleanly, hg import --partial will create an empty changeset, importing only the patch metadata.
With -s/--similarity, hg will attempt to discover renames and copies in the patch in the same way as hg addremove.
It is possible to use external patch programs to perform the patch by setting the ui.patch configuration option. For the default internal tool, the fuzz can also be configured via patch.fuzz.  See hg help config for more information about configuration files and how to use these options.
• import a traditional patch from a website and detect renames:
hg import -s 80 http://example.com/bugfix.patch
• import a changeset from an hgweb server:
hg import https://www.mercurial-scm.org/repo/hg/rev/5ca8c111e9aa
• import all the patches in an Unix-style mbox:
hg import incoming-patches.mbox
• import patches from stdin:
hg import -
• attempt to exactly restore an exported changeset (not always possible):
hg import --exact proposed-fix.patch
• use an external tool to apply a patch which is too fuzzy for the default internal tool.
hg import --config ui.patch="patch --merge" fuzzy.patch
• change the default fuzzing from 2 to a less strict 7
hg import --config ui.fuzz=7 fuzz.patch
Returns 0 on success, 1 on partial success (see --partial).
-p,--strip <NUM> directory strip option for patch. This has the same meaning as the corresponding patch option (default: 1)
-b,--base <PATH> base path (DEPRECATED)
--secret use the secret phase for committing
-f, --force skip check for outstanding uncommitted changes (DEPRECATED)
--no-commit don't commit, just update the working directory
--bypass apply patch without touching the working directory
--partial commit even if some hunks fail
--exact abort if patch would apply lossily
--prefix <DIR> apply patch to subdirectory
--import-branch use any branch information in patch (implied by --exact)
aliases: patch
unbundle apply one or more bundle files:
hg unbundle [-u] FILE...
Apply one or more bundle files generated by hg bundle.
Returns 0 on success, 1 if an update has unresolved files.
-u, --update update to new branch head if changesets were unbundled
Repository maintenance manifest output the current or given revision of the project manifest:
hg manifest [-r REV]
Print a list of version controlled files for the given revision.  If no revision is given, the first parent of the working directory is used, or the null revision if no revision is checked out.
With -v, print file permissions, symlink and executable bits.  With --debug, print file revision hashes.
If option --all is specified, the list of all files from all revisions is printed. This includes deleted and renamed files.
-r,--rev <REV> revision to display
--all  list files from all revisions
recover roll back an interrupted transaction:
hg recover
Recover from an interrupted commit or pull.
This command tries to fix the repository status after an interrupted operation. It should only be necessary when Mercurial suggests it.
Returns 0 if successful, 1 if nothing to recover or verify fails.
--verify run hg verify after successful recover
rollback roll back the last transaction (DANGEROUS) (DEPRECATED):
hg rollback
Please use hg commit --amend instead of rollback to correct mistakes in the last commit.
This command should be used with care. There is only one level of rollback, and there is no way to undo a rollback. It will also restore the dirstate at the time of the last transaction, losing any dirstate changes since that time. This command does not alter the working directory.
Transactions are used to encapsulate the effects of all commands that create new changesets or propagate existing changesets into a repository.
For example, the following commands are transactional, and their effects can be rolled back:
• commit
• import
• push (with this repository as the destination)
• unbundle
To avoid permanent data loss, rollback will refuse to rollback a commit transaction if it isn't checked out. Use --force to override this protection.
The rollback command can be entirely disabled by setting the ui.rollback configuration setting to false. If you're here because you want to use rollback and it's disabled, you can re-enable the command by setting ui.rollback to true.
This command is not intended for use on public repositories. Once changes are visible for pull by other users, rolling a transaction back locally is ineffective (someone else may already have pulled the changes). Furthermore, a race is possible with readers of the repository; for example an in-progress pull from the repository may fail if a rollback is performed.
Returns 0 on success, 1 if no rollback data is available.
-f, --force ignore safety measures
verify verify the integrity of the repository:
hg verify
Verify the integrity of the current repository.
This will perform an extensive check of the repository's integrity, validating the hashes and checksums of each entry in the changelog, manifest, and tracked files, as well as the integrity of their crosslinks and indices.
Please see https://mercurial-scm.org/wiki/RepositoryCorruption for more information about recovery from corruption of the repository.
--full perform more checks (EXPERIMENTAL)
Help config show combined config settings from all hgrc files:
hg config [-u] [NAME]...
With no arguments, print names and values of all config items.
With one argument of the form section.name, print just the value of that config item.
With multiple arguments, print names and values of all config items with matching section names or section.names.
With --edit, start an editor on the user-level config file. With --global, edit the system-wide config file. With --local, edit the repository-level config file.
With --source, the source (filename and line number) is printed for each config item.
See hg help config for more information about config files.
--non-shared flag is used to edit .hg/hgrc-not-shared config file.  This file is not shared across shares when in share-safe mode.
name   String. Config name.
source String. Filename and line number where the item is defined.
value  String. Config value.
The --shared flag can be used to edit the config file of shared source repository. It only works when you have shared using the experimental share safe feature.
Returns 0 on success, 1 if NAME does not exist.
-u, --untrusted show untrusted configuration options
--exp-all-known show all known config option (EXPERIMENTAL)
-e, --edit edit user config
-l, --local edit repository config
--source show source of configuration value
--shared edit shared source repository config (EXPERIMENTAL)
--non-shared edit non shared config (EXPERIMENTAL)
-g, --global edit global config
aliases: showconfig debugconfig
help show help for a given topic or a help overview:
hg help [-eck] [-s PLATFORM] [TOPIC]
With no arguments, print a list of commands with short help messages.
Given a topic, extension, or command name, print help for that topic.
-e, --extension show only help for extensions
-c, --command show only help for commands
-k, --keyword show topics matching keyword
-s,--system <PLATFORM[+]> show help for specific platform(s)
version output version and copyright information:
extensions List of extensions.
ver    String. Version number.
And each entry of {extensions} provides the following sub-keywords in addition to {ver}.
bundled Boolean. True if included in the release.
name   String. Extension name.
Mercurial supports generating standalone "bundle" files that hold repository data. These "bundles" are typically saved locally and used later or exchanged between different repositories, possibly on different machines. Example commands using bundles are hg bundle and hg unbundle.
Generation of bundle files is controlled by a "bundle specification" ("bundlespec") string. This string tells the bundle generation process how to create the bundle.
A "bundlespec" string is composed of the following elements:
type   A string denoting the bundle format to use.
compression Denotes the compression engine to use compressing the raw bundle data.
parameters Arbitrary key-value parameters to further control bundle generation.
A "bundlespec" string has the following formats:
<type> The literal bundle format string is used.
<compression>-<type> The compression engine and format are delimited by a hyphen (-).
Optional parameters follow the <type>. Parameters are URI escaped key=value pairs. Each pair is delimited by a semicolon (;). The first parameter begins after a ; immediately following the <type> value.
Available Types The following bundle <type> strings are available:
v1     Produces a legacy "changegroup" version 1 bundle.
This format is compatible with nearly all Mercurial clients because it is the oldest. However, it has some limitations, which is why it is no longer the default for new repositories.
v1 bundles can be used with modern repositories using the "generaldelta" storage format. However, it may take longer to produce the bundle and the resulting bundle may be significantly larger than a v2 bundle.
v1 bundles can only use the gzip, bzip2, and none compression formats.
v2     Produces a version 2 bundle.
Version 2 bundles are an extensible format that can store additional repository data (such as bookmarks and phases information) and they can store data more efficiently, resulting in smaller bundles.
Version 2 bundles can also use modern compression engines, such as zstd, making them faster to compress and often smaller.
Available Compression Engines The following bundle <compression> engines can be used:
An algorithm that produces smaller bundles than gzip.
All Mercurial clients should support this format.
This engine will likely produce smaller bundles than gzip but will be significantly slower, both during compression and decompression.
If available, the zstd engine can yield similar or better compression at much higher speeds.
zlib compression using the DEFLATE algorithm.
All Mercurial clients should support this format. The compression algorithm strikes a reasonable balance between compression ratio and size.
No compression is performed.
Use this compression engine to explicitly disable compression.
Produce a v2 bundle using default options, including compression.
none-v1
Produce a v1 bundle with no compression.
zstd-v2
Produce a v2 bundle with zstandard compression using default settings.
zstd-v1
This errors because zstd is not supported for v1 types.
Mercurial colorizes output from several commands.
For example, the diff command shows additions in green and deletions in red, while the status command shows modified files in magenta. Many other commands have analogous colors. It is possible to customize these colors.
To enable color (default) whenever possible use:
[ui] color = yes
To disable color use:
[ui] color = no
See hg help config.ui.color for details.
The default pager on Windows does not support color, so enabling the pager will effectively disable color.  See hg help config.ui.paginate to disable the pager.  Alternately, MSYS and Cygwin shells provide less as a pager, which can be configured to support ANSI color mode.  Windows 10 natively supports ANSI color mode.
Mode Mercurial can use various systems to display color. The supported modes are ansi, win32, and terminfo.  See hg help config.color for details about how to control the mode.
Effects Other effects in addition to color, like bold and underlined text, are also available. By default, the terminfo database is used to find the terminal codes used to change color and effect.  If terminfo is not available, then effects are rendered with the ECMA-48 SGR control function (aka ANSI escape codes).
The available effects in terminfo mode are 'blink', 'bold', 'dim', 'inverse', 'invisible', 'italic', 'standout', and 'underline'; in ECMA-48 mode, the options are 'bold', 'inverse', 'italic', and 'underline'.  How each is rendered depends on the terminal emulator.  Some may not be available for a given terminal type, and will be silently ignored.
If the terminfo entry for your terminal is missing codes for an effect or has the wrong codes, you can add or override those codes in your configuration:
[color] terminfo.dim = \E[2m
where 'E' is substituted with an escape character.
Labels Text receives color effects depending on the labels that it has. Many default Mercurial commands emit labelled text. You can also define your own labels in templates using the label function, see hg help templates. A single portion of text may have more than one label. In that case, effects given to the last label will override any other effects. This includes the special "none" effect, which nullifies other effects.
Labels are normally invisible. In order to see these labels and their position in the text, use the global --color=debug option. The same anchor text may be associated to multiple labels, e.g.
[log.changeset changeset.secret|changeset:   22611:6f0a53c8f587]
The following are the default effects for some default labels. Default effects may be overridden from your configuration file:
[color] status.modified = blue bold underline red_background status.added = green bold status.removed = red bold blue_background status.deleted = cyan bold underline status.unknown = magenta bold underline status.ignored = black bold
# 'none' turns off all effects status.clean = none status.copied = none
qseries.applied = blue bold underline qseries.unapplied = black bold qseries.missing = red bold
diff.diffline = bold diff.extended = cyan bold diff.file_a = red bold diff.file_b = green bold diff.hunk = magenta diff.deleted = red diff.inserted = green diff.changed = white diff.tab = diff.trailingwhitespace = bold red_background
# Blank so it inherits the style of the surrounding label changeset.public = changeset.draft = changeset.secret =
resolve.unresolved = red bold resolve.resolved = green bold
bookmarks.active = green
branches.active = none branches.closed = black bold branches.current = green branches.inactive = none
tags.normal = green tags.local = black bold
rebase.rebased = blue rebase.remaining = red bold
shelve.age = cyan shelve.newest = green bold shelve.name = blue bold
histedit.remaining = red bold
Custom colors Because there are only eight standard colors, Mercurial allows you to define color names for other color slots which might be available for your terminal type, assuming terminfo mode.  For instance:
color.brightblue = 12 color.pink = 207 color.orange = 202
to set 'brightblue' to color slot 12 (useful for 16 color terminals that have brighter colors defined in the upper eight) and, 'pink' and 'orange' to colors in 256-color xterm's default color cube.  These defined colors may then be used as any of the pre-defined eight, including appending '_background' to set the background to that color.
Some commands allow the user to specify a date, e.g.:
• backout, commit, import, tag: Specify the commit date.
• log, revert, update: Select revision(s) by date.
Many date formats are valid. Here are some examples:
• Wed Dec 6 13:18:29 2006 (local timezone assumed)
• Dec 6 13:18 -0600 (year assumed, time offset provided)
• Dec 6 13:18 UTC (UTC and GMT are aliases for +0000)
• Dec 6 (midnight)
• 13:18 (today assumed)
• 3:39 (3:39AM assumed)
• 3:39pm (15:39)
• 2006-12-06 13:18:29 (ISO 8601 format)
• 2006-12-6 13:18
• 2006-12-6
• 12-6
• 12/6
• 12/6/6 (Dec 6 2006)
• today (midnight)
• yesterday (midnight)
• now - right now
Lastly, there is Mercurial's internal format:
• 1165411109 0 (Wed Dec 6 13:18:29 2006 UTC)
This is the internal representation format for dates. The first number is the number of seconds since the epoch (1970-01-01 00:00 UTC). The second is the offset of the local timezone, in seconds west of UTC (negative if the timezone is east of UTC).
The log command also accepts date ranges:
• <DATE - at or before a given date/time
• >DATE - on or after a given date/time
• DATE to DATE - a date range, inclusive
• -DAYS - within a given number of days from today
Mercurial evolves over time, some features, options, commands may be replaced by better and more secure alternatives. This topic will help you migrating your existing usage and/or configuration to newer features.
Commands The following commands are still available but their use are not recommended:
This command has been replaced by hg files.
This command can be replaced by hg summary or hg log with appropriate revsets. See hg help revsets for more information.
The recommended alternative is hg heads.
Options web.allowpull
Renamed to allow-pull.
web.allow_push
Renamed to allow-push.
Mercurial's default format for showing changes between two versions of a file is compatible with the unified format of GNU diff, which can be used by GNU patch and many other standard tools.
While this standard format is often enough, it does not encode the following information:
• executable status and other permission bits
• copy or rename information
• changes in binary files
• creation or deletion of empty files
Mercurial also supports the extended diff format from the git VCS which addresses these limitations. The git diff format is not produced by default because a few widespread tools still do not understand this format.
This means that when generating diffs from a Mercurial repository (e.g. with hg export), you should be careful about things like file copies and renames or other things mentioned above, because when applying a standard diff to a different repository, this extra information is lost. Mercurial's internal operations (like push and pull) are not affected by this, because they use an internal binary format for communicating changes.
To make Mercurial produce the git extended diff format, use the --git option available for many commands, or set 'git = True' in the [diff] section of your configuration file. You do not need to set this option when importing diffs in this format or using them in the mq extension.
HG     Path to the 'hg' executable, automatically passed when running hooks, extensions or external tools. If unset or empty, this is the hg executable's name if it's frozen, or an executable named 'hg' (with %PATHEXT% [defaulting to COM/EXE/BAT/CMD] extensions on Windows) is searched.
HGEDITOR This is the name of the editor to run when committing. See EDITOR.
(deprecated, see hg help config.ui.editor)
HGENCODING This overrides the default locale setting detected by Mercurial. This setting is used to convert data including usernames, changeset descriptions, tag names, and branches. This setting can be overridden with the --encoding command-line option.
HGENCODINGMODE This sets Mercurial's behavior for handling unknown characters while transcoding user input. The default is "strict", which causes Mercurial to abort if it can't map a character. Other settings include "replace", which replaces unknown characters, and "ignore", which drops them. This setting can be overridden with the --encodingmode command-line option.
HGENCODINGAMBIGUOUS This sets Mercurial's behavior for handling characters with "ambiguous" widths like accented Latin characters with East Asian fonts. By default, Mercurial assumes ambiguous characters are narrow, set this variable to "wide" if such characters cause formatting problems.
HGMERGE An executable to use for resolving merge conflicts. The program will be executed with three arguments: local file, remote file, ancestor file.
(deprecated, see hg help config.ui.merge)
HGRCPATH A list of files or directories to search for configuration files. Item separator is ":" on Unix, ";" on Windows. If HGRCPATH is not set, platform default search path is used. If empty, only the .hg/hgrc from the current repository is read.
For each element in HGRCPATH:
• if it's a directory, all files ending with .rc are added
• otherwise, the file itself will be added
HGRCSKIPREPO When set, the .hg/hgrc from repositories are not read.
HGPLAIN When set, this disables any configuration settings that might change Mercurial's default output. This includes encoding, defaults, verbose mode, debug mode, quiet mode, tracebacks, and localization. This can be useful when scripting against Mercurial in the face of existing user configuration.
In addition to the features disabled by HGPLAIN=, the following values can be specified to adjust behavior:
+strictflags
Restrict parsing of command line flags.
Equivalent options set via command line flags or environment variables are not overridden.
See hg help scripting for details.