neulab/tldr huggingface dataset:
See hg help templates for information on templates and filters.
-d, --default show default keyword template maps
-f,--rcfile <FILE> read maps from rcfile
kwexpand expand keywords in the working directory:
hg kwexpand [OPTION]... [FILE]...
Run after (re)enabling keyword expansion.
kwexpand refuses to run if given files contain local changes.
kwfiles show files configured for keyword expansion:
hg kwfiles [OPTION]... [FILE]...
List which files in the working directory are matched by the [keyword] configuration patterns.
Useful to prevent inadvertent keyword expansion and to speed up execution by including only files that are actual candidates for expansion.
See hg help keyword on how to construct patterns both for inclusion and exclusion of files.
With -A/--all and -v/--verbose the codes used to show the status of files are:
K = keyword expansion candidate k = keyword expansion candidate (not tracked) I = ignored i = ignored (not tracked)
-A, --all show keyword status flags of all files
-i, --ignore show files excluded from expansion
-u, --unknown only show unknown (not tracked) files
kwshrink revert expanded keywords in the working directory:
hg kwshrink [OPTION]... [FILE]...
Must be run before changing/disabling active keywords.
kwshrink refuses to run if given files contain local changes.
Large binary files tend to be not very compressible, not very diffable, and not at all mergeable. Such files are not handled efficiently by Mercurial's storage format (revlog), which is based on compressed binary deltas; storing large binary files as regular Mercurial files wastes bandwidth and disk space and increases Mercurial's memory usage. The largefiles extension addresses these problems by adding a centralized client-server layer on top of Mercurial: largefiles live in a central store out on the network somewhere, and you only fetch the revisions that you need when you need them.
largefiles works by maintaining a "standin file" in .hglf/ for each largefile. The standins are small (41 bytes: an SHA-1 hash plus newline) and are tracked by Mercurial. Largefile revisions are identified by the SHA-1 hash of their contents, which is written to the standin. largefiles uses that revision ID to get/put largefile revisions from/to the central store. This saves both disk space and bandwidth, since you don't need to retrieve all historical revisions of large files when you clone or pull.
To start a new repository or add new large binary files, just add --large to your hg add command. For example:
$ dd if=/dev/urandom of=randomdata count=2000 $ hg add --large randomdata $ hg commit -m "add randomdata as a largefile"
When you push a changeset that adds/modifies largefiles to a remote repository, its largefile revisions will be uploaded along with it.  Note that the remote Mercurial must also have the largefiles extension enabled for this to work.
When you pull a changeset that affects largefiles from a remote repository, the largefiles for the changeset will by default not be pulled down. However, when you update to such a revision, any largefiles needed by that revision are downloaded and cached (if they have never been downloaded before). One way to pull largefiles when pulling is thus to use --update, which will update your working copy to the latest pulled revision (and thereby downloading any new largefiles).
If you want to pull largefiles you don't need for update yet, then you can use pull with the --lfrev option or the hg lfpull command.
If you know you are pulling from a non-default location and want to download all the largefiles that correspond to the new changesets at the same time, then you can pull with --lfrev "pulled()".
If you just want to ensure that you will have the largefiles needed to merge or rebase with new heads that you are pulling, then you can pull with --lfrev "head(pulled())" flag to pre-emptively download any largefiles that are new in the heads you are pulling.
Keep in mind that network access may now be required to update to changesets that you have not previously updated to. The nature of the largefiles extension means that updating is no longer guaranteed to be a local-only operation.
If you already have large files tracked by Mercurial without the largefiles extension, you will need to convert your repository in order to benefit from largefiles. This is done with the hg lfconvert command:
$ hg lfconvert --size 10 oldrepo newrepo
In repositories that already have largefiles in them, any new file over 10MB will automatically be added as a largefile. To change this threshold, set largefiles.minsize in your Mercurial config file to the minimum size in megabytes to track as a largefile, or use the --lfsize option to the add command (also in megabytes):
[largefiles] minsize = 2
$ hg add --lfsize 2
The largefiles.patterns config option allows you to specify a list of filename patterns (see hg help patterns) that should always be tracked as largefiles:
[largefiles] patterns = *.jpg re:.*\.(png|bmp)$ library.zip content/audio/*
Files that match one of these patterns will be added as largefiles regardless of their size.
The largefiles.minsize and largefiles.patterns config options will be ignored for any repositories not already containing a largefile. To add the first largefile to a repository, you must explicitly do so with the --large flag passed to the hg add command.
Commands Uncategorized commands lfconvert convert a normal repository to a largefiles repository:
hg lfconvert SOURCE DEST [FILE ...]
Convert repository SOURCE to a new repository DEST, identical to SOURCE except that certain files will be converted as largefiles: specifically, any file that matches any PATTERN or whose size is above the minimum size threshold is converted as a largefile. The size used to determine whether or not to track a file as a largefile is the size of the first version of the file. The minimum size can be specified either with --size or in configuration as largefiles.size.
After running this command you will need to make sure that largefiles is enabled anywhere you intend to push the new repository.
Use --to-normal to convert largefiles back to normal files; after this, the DEST repository can be used without largefiles at all.
-s,--size <SIZE> minimum size (MB) for files to be converted as largefiles
--to-normal convert from a largefiles repo to a normal repo
lfpull pull largefiles for the specified revisions from the specified source:
hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [SOURCE]
Pull largefiles that are referenced from local changesets but missing locally, pulling from a remote repository to the local cache.
• pull largefiles for all branch heads:
hg lfpull -r "head() and not closed()"
• pull largefiles on the default branch:
hg lfpull -r "branch(default)"
-r,--rev <VALUE[+]> pull largefiles for these revisions
lfs lfs - large file support (EXPERIMENTAL)
This extension allows large files to be tracked outside of the normal repository storage and stored on a centralized server, similar to the largefiles extension.  The git-lfs protocol is used when communicating with the server, so existing git infrastructure can be harnessed.  Even though the files are stored outside of the repository, they are still integrity checked in the same manner as normal files.
The files stored outside of the repository are downloaded on demand, which reduces the time to clone, and possibly the local disk usage.  This changes fundamental workflows in a DVCS, so careful thought should be given before deploying it.  hg convert can be used to convert LFS repositories to normal repositories that no longer require this extension, and do so without changing the commit hashes.  This allows the extension to be disabled if the centralized workflow becomes burdensome. However, the pre and post convert clones will not be able to communicate with each other unless the extension is enabled on both.
To start a new repository, or to add LFS files to an existing one, just create an .hglfs file as described below in the root directory of the repository.  Typically, this file should be put under version control, so that the settings will propagate to other repositories with push and pull.  During any commit, Mercurial will consult this file to determine if an added or modified file should be stored externally.  The type of storage depends on the characteristics of the file at each commit.  A file that is near a size threshold may switch back and forth between LFS and normal storage, as needed.
Alternately, both normal repositories and largefile controlled repositories can be converted to LFS by using hg convert and the lfs.track config option described below.  The .hglfs file should then be created and added, to control subsequent LFS selection.  The hashes are also unchanged in this case.  The LFS and non-LFS repositories can be distinguished because the LFS repository will abort any command if this extension is disabled.
Committed LFS files are held locally, until the repository is pushed. Prior to pushing the normal repository data, the LFS files that are tracked by the outgoing commits are automatically uploaded to the configured central server.  No LFS files are transferred on hg pull or hg clone.  Instead, the files are downloaded on demand as they need to be read, if a cached copy cannot be found locally.  Both committing and downloading an LFS file will link the file to a usercache, to speed up future access.  See the usercache config setting described below.
The extension reads its configuration from a versioned .hglfs configuration file found in the root of the working directory. The .hglfs file uses the same syntax as all other Mercurial configuration files. It uses a single section, [track].
The [track] section specifies which files are stored as LFS (or not). Each line is keyed by a file pattern, with a predicate value.  The first file pattern match is used, so put more specific patterns first.  The available predicates are all(), none(), and size(). See "hg help filesets.size" for the latter.
Example versioned .hglfs file:
[track] # No Makefile or python file, anywhere, will be LFS **Makefile = none() **.py = none()
**.zip = all() **.exe = size(">1MB")
# Catchall for everything not matched above ** = size(">10MB")
Configs:
[lfs] # Remote endpoint. Multiple protocols are supported: # - http(s)://user:pass@example.com/path #   git-lfs endpoint # - file:///tmp/path #   local filesystem, usually for testing # if unset, lfs will assume the remote repository also handles blob storage # for http(s) URLs.  Otherwise, lfs will prompt to set this when it must # use this value. # (default: unset) url = https://example.com/repo.git/info/lfs
# Which files to track in LFS.  Path tests are "**.extname" for file # extensions, and "path:under/some/directory" for path prefix.  Both # are relative to the repository root. # File size can be tested with the "size()" fileset, and tests can be # joined with fileset operators.  (See "hg help filesets.operators".) # # Some examples: # - all()                       # everything # - none()                      # nothing # - size(">20MB")               # larger than 20MB # - !**.txt                     # anything not a *.txt file # - **.zip | **.tar.gz | **.7z  # some types of compressed files # - path:bin                    # files under "bin" in the project root # - (**.php & size(">2MB")) | (**.js & size(">5MB")) | **.tar.gz #     | (path:bin & !path:/bin/README) | size(">1GB") # (default: none()) # # This is ignored if there is a tracked '.hglfs' file, and this setting # will eventually be deprecated and removed. track = size(">10M")
# how many times to retry before giving up on transferring an object retry = 5
# the local directory to store lfs files for sharing across local clones. # If not set, the cache is located in an OS specific cache location. usercache = /path/to/global/cache
Commands Uncategorized commands logtoprocess send ui.log() data to a subprocess (EXPERIMENTAL)
This extension lets you specify a shell command per ui.log() event, sending all remaining arguments to as environment variables to that command.
Positional arguments construct a log message, which is passed in the MSG1 environment variables. Each keyword argument is set as a OPT_UPPERCASE_KEY variable (so the key is uppercased, and prefixed with OPT_). The original event name is passed in the EVENT environment variable, and the process ID of mercurial is given in HGPID.
So given a call ui.log('foo', 'bar %s ', 'baz', spam='eggs'), a script configured for the `foo event can expect an environment with MSG1=bar baz, and OPT_SPAM=eggs.
Scripts are configured in the [logtoprocess] section, each key an event name.  For example:
[logtoprocess] commandexception = echo "$MSG1" > /var/log/mercurial_exceptions.log
would log the warning message and traceback of any failed command dispatch.
Scripts are run asynchronously as detached daemon processes; mercurial will not ensure that they exit cleanly.
mq manage a stack of patches
This extension lets you work with a stack of patches in a Mercurial repository. It manages two stacks of patches - all known patches, and applied patches (subset of known patches).
Known patches are represented as patch files in the .hg/patches directory. Applied patches are both patch files and changesets.
Common tasks (use hg help COMMAND for more details):
create new patch                          qnew import existing patch                     qimport
print patch series                        qseries print applied patches                     qapplied
add known patch to applied stack          qpush remove patch from applied stack           qpop refresh contents of top applied patch     qrefresh
By default, mq will automatically use git patches when required to avoid losing file mode changes, copy records, binary files or empty files creations or deletions. This behavior can be configured with:
[mq] git = auto/keep/yes/no
If set to 'keep', mq will obey the [diff] section configuration while preserving existing git patches upon qrefresh. If set to 'yes' or 'no', mq will override the [diff] section and always generate git or regular patches, possibly losing data in the second case.
It may be desirable for mq changesets to be kept in the secret phase (see hg help phases), which can be enabled with the following setting:
[mq] secret = True
You will by default be managing a patch queue named "patches". You can create other, independent patch queues with the hg qqueue command.
If the working directory contains uncommitted files, qpush, qpop and qgoto abort immediately. If -f/--force is used, the changes are discarded. Setting:
[mq] keepchanges = True
make them behave as if --keep-changes were passed, and non-conflicting local changes will be tolerated and preserved. If incompatible options such as -f/--force or --exact are passed, this setting is ignored.
This extension used to provide a strip command. This command now lives in the strip extension.
Commands Repository creation qclone clone main and patch repository at same time:
hg qclone [OPTION]... SOURCE [DEST]
If source is local, destination will have no patches applied. If source is remote, this command can not check if patches are applied in source, so cannot guarantee that patches are not applied in destination. If you clone remote repository, be sure before that it has no patches applied.
Source patch repository is looked for in <src>/.hg/patches by default. Use -p <url> to change.
The patch directory must be a nested Mercurial repository, as would be created by hg init --mq.
-U, --noupdate do not update the new working directories
--uncompressed use uncompressed transfer (fast over LAN)
-p,--patches <REPO> location of source patch repository
qinit init a new queue repository (DEPRECATED):
hg qinit [-c]
The queue repository is unversioned by default. If -c/--create-repo is specified, qinit will create a separate nested repository for patches (qinit -c may also be run later to convert an unversioned patch repository into a versioned one). You can use qcommit to commit changes to this queue repository.
This command is deprecated. Without -c, it's implied by other relevant commands. With -c, use hg init --mq instead.
-c, --create-repo create queue repository
Change creation qcommit commit changes in the queue repository (DEPRECATED):
hg qcommit [OPTION]... [FILE]...
This command is deprecated; use hg commit --mq instead.
aliases: qci
qnew create a new patch:
hg qnew [-e] [-m TEXT] [-l FILE] PATCH [FILE]...
qnew creates a new patch on top of the currently-applied patch (if any). The patch will be initialized with any outstanding changes in the working directory. You may also use -I/--include, -X/--exclude, and/or a list of files after the patch name to add only changes to matching files to the new patch, leaving the rest as uncommitted modifications.
-u/--user and -d/--date can be used to set the (given) user and date, respectively. -U/--currentuser and -D/--currentdate set user to current user and date to current date.
-e/--edit, -m/--message or -l/--logfile set the patch header as well as the commit message. If none is specified, the header is empty and the commit message is '[mq]: PATCH'.
Use the -g/--git option to keep the patch in the git extended diff format. Read the diffs help topic for more information on why this is important for preserving permission changes and copy/rename information.
Returns 0 on successful creation of a new patch.
-f, --force import uncommitted changes (DEPRECATED)
-U, --currentuser add "From: <current user>" to patch
-u,--user <USER> add "From: <USER>" to patch
-D, --currentdate add "Date: <current date>" to patch
-d,--date <DATE> add "Date: <DATE>" to patch
qrefresh update the current patch:
hg qrefresh [-I] [-X] [-e] [-m TEXT] [-l FILE] [-s] [FILE]...
If any file patterns are provided, the refreshed patch will contain only the modifications that match those patterns; the remaining modifications will remain in the working directory.
If -s/--short is specified, files currently included in the patch will be refreshed just like matched files and remain in the patch.
If -e/--edit is specified, Mercurial will start your configured editor for you to enter a message. In case qrefresh fails, you will find a backup of your message in .hg/last-message.txt.
hg add/remove/copy/rename work as usual, though you might want to use git-style patches (-g/--git or [diff] git=1) to track copies and renames. See the diffs help topic for more information on the git diff format.
-s, --short refresh only files already in the patch and specified files
-U, --currentuser add/update author field in patch with current user
-u,--user <USER> add/update author field in patch with given user
-D, --currentdate add/update date field in patch with current date
-d,--date <DATE> add/update date field in patch with given date
Change manipulation qfold fold the named patches into the current patch:
hg qfold [-e] [-k] [-m TEXT] [-l FILE] PATCH...
Patches must not yet be applied. Each patch will be successively applied to the current patch in the order given. If all the patches apply successfully, the current patch will be refreshed with the new cumulative patch, and the folded patches will be deleted. With -k/--keep, the folded patch files will not be removed afterwards.
The header for each folded patch will be concatenated with the current patch header, separated by a line of * * *.
-k, --keep keep folded patch files
Change organization qapplied print the patches already applied:
hg qapplied [-1] [-s] [PATCH]
-1, --last show only the preceding applied patch
-s, --summary print first line of patch header
qdelete remove patches from queue:
hg qdelete [-k] [PATCH]...
The patches must not be applied, and at least one patch is required. Exact patch identifiers must be given. With -k/--keep, the patch files are preserved in the patch directory.
To stop managing a patch and move it into permanent history, use the hg qfinish command.
-k, --keep keep patch file
-r,--rev <REV[+]> stop managing a revision (DEPRECATED)
aliases: qremove qrm
qfinish move applied patches into repository history:
hg qfinish [-a] [REV]...
Finishes the specified revisions (corresponding to applied patches) by moving them out of mq control into regular repository history.
Accepts a revision range or the -a/--applied option. If --applied is specified, all applied mq revisions are removed from mq control. Otherwise, the given revisions must be at the base of the stack of applied patches.
This can be especially useful if your changes have been applied to an upstream repository, or if you are about to push your changes to upstream.
-a, --applied finish all applied changesets
qgoto push or pop patches until named patch is at top of stack:
hg qgoto [OPTION]... PATCH
--keep-changes tolerate non-conflicting local changes
-f, --force overwrite any local changes
--no-backup do not save backup copies of files
qguard set or print guards for a patch:
hg qguard [-l] [-n] [PATCH] [-- [+GUARD]... [-GUARD]...]
Guards control whether a patch can be pushed. A patch with no guards is always pushed. A patch with a positive guard ("+foo") is pushed only if the hg qselect command has activated it. A patch with a negative guard ("-foo") is never pushed if the hg qselect command has activated it.
With no arguments, print the currently active guards.  With arguments, set guards for the named patch.
Note   Specifying negative guards now requires '--'.
To set guards on another patch:
hg qguard other.patch -- +2.6.17 -stable
-l, --list list all patches and guards
-n, --none drop all guards
qheader print the header of the topmost or specified patch:
hg qheader [PATCH]
qnext print the name of the next pushable patch:
hg qnext [-s]
qpop pop the current patch off the stack:
hg qpop [-a] [-f] [PATCH | INDEX]
Without argument, pops off the top of the patch stack. If given a patch name, keeps popping off patches until the named patch is at the top of the stack.
By default, abort if the working directory contains uncommitted changes. With --keep-changes, abort only if the uncommitted files overlap with patched files. With -f/--force, backup and discard changes made to such files.
-a, --all pop all patches
-n,--name <NAME> queue name to pop (DEPRECATED)
-f, --force forget any local changes to patched files
qprev print the name of the preceding applied patch:
hg qprev [-s]
qpush push the next patch onto the stack:
hg qpush [-f] [-l] [-a] [--move] [PATCH | INDEX]
By default, abort if the working directory contains uncommitted changes. With --keep-changes, abort only if the uncommitted files overlap with patched files. With -f/--force, backup and patch over uncommitted changes.
-f, --force apply on top of local changes
-e, --exact apply the target patch to its recorded parent
-l, --list list patch name in commit text
-a, --all apply all patches
-m, --merge merge from another queue (DEPRECATED)
-n,--name <NAME> merge queue name (DEPRECATED)
--move reorder patch series and apply only the patch
qqueue manage multiple patch queues:
hg qqueue [OPTION] [QUEUE]
Supports switching between different patch queues, as well as creating new patch queues and deleting existing ones.
Omitting a queue name or specifying -l/--list will show you the registered queues - by default the "normal" patches queue is registered. The currently active queue will be marked with "(active)". Specifying --active will print only the name of the active queue.
To create a new queue, use -c/--create. The queue is automatically made active, except in the case where there are applied patches from the currently active queue in the repository. Then the queue will only be created and switching will fail.
To delete an existing queue, use --delete. You cannot delete the currently active queue.
-l, --list list all available queues
--active print name of active queue
-c, --create create new queue
--rename rename active queue
--delete delete reference to queue
--purge delete queue, and remove patch dir
qrename rename a patch:
hg qrename PATCH1 [PATCH2]
With one argument, renames the current patch to PATCH1.  With two arguments, renames PATCH1 to PATCH2.
aliases: qmv
qrestore restore the queue state saved by a revision (DEPRECATED):
hg qrestore [-d] [-u] REV
This command is deprecated, use hg rebase instead.
-d, --delete delete save entry
-u, --update update queue working directory
qsave save current queue state (DEPRECATED):
hg qsave [-m TEXT] [-l FILE] [-c] [-n NAME] [-e] [-f]
-c, --copy copy patch directory
-n,--name <NAME> copy directory name
-e, --empty clear queue status file
-f, --force force copy
qselect set or print guarded patches to push:
hg qselect [OPTION]... [GUARD]...
Use the hg qguard command to set or print guards on patch, then use qselect to tell mq which guards to use. A patch will be pushed if it has no guards or any positive guards match the currently selected guard, but will not be pushed if any negative guards match the current guard. For example:
qguard foo.patch -- -stable    (negative guard) qguard bar.patch    +stable    (positive guard) qselect stable
This activates the "stable" guard. mq will skip foo.patch (because it has a negative match) but push bar.patch (because it has a positive match).
With no arguments, prints the currently active guards.  With one argument, sets the active guard.
Use -n/--none to deactivate guards (no other arguments needed).  When no guards are active, patches with positive guards are skipped and patches with negative guards are pushed.
qselect can change the guards on applied patches. It does not pop guarded patches by default. Use --pop to pop back to the last applied patch that is not guarded. Use --reapply (which implies --pop) to push back to the current patch afterwards, but skip guarded patches.
Use -s/--series to print a list of all guards in the series file (no other arguments needed). Use -v for more information.
-n, --none disable all guards
-s, --series list all guards in series file
--pop  pop to before first guarded applied patch
--reapply pop, then reapply patches
qseries print the entire series file:
hg qseries [-ms]
-m, --missing print patches not in series
qtop print the name of the current patch:
hg qtop [-s]
qunapplied print the patches not yet applied:
hg qunapplied [-1] [-s] [PATCH]
-1, --first show only the first patch
File content management qdiff diff of the current patch and subsequent modifications:
hg qdiff [OPTION]... [FILE]...
Shows a diff which includes the current patch as well as any changes which have been made in the working directory since the last refresh (thus showing what the current patch would become after a qrefresh).
Use hg diff if you only want to see the changes made since the last qrefresh, or hg export qtip if you want to see changes made by the current patch without including changes made since the qrefresh.
Change import/export qimport import a patch or existing changeset:
hg qimport [-e] [-n NAME] [-f] [-g] [-P] [-r REV]... [FILE]...
The patch is inserted into the series after the last applied patch. If no patches have been applied, qimport prepends the patch to the series.
The patch will have the same name as its source file unless you give it a new one with -n/--name.
You can register an existing patch inside the patch directory with the -e/--existing flag.
With -f/--force, an existing patch of the same name will be overwritten.
An existing changeset may be placed under mq control with -r/--rev (e.g. qimport --rev . -n patch will place the current revision under mq control). With -g/--git, patches imported with --rev will use the git diff format. See the diffs help topic for information on why this is important for preserving rename/copy information and permission changes. Use hg qfinish to remove changesets from mq control.
To import a patch from standard input, pass - as the patch file.  When importing from standard input, a patch name must be specified using the --name flag.
To import an existing patch while renaming it:
hg qimport -e existing-patch -n new-name
Returns 0 if import succeeded.
-e, --existing import file in patch directory
-n,--name <NAME> name of patch file
-f, --force overwrite existing files
-r,--rev <REV[+]> place existing revisions under mq control
-P, --push qpush after importing
narrow create clones which fetch history data for subset of files (EXPERIMENTAL)
Commands Repository maintenance tracked show or change the current narrowspec:
hg tracked [OPTIONS]... [REMOTE]
With no argument, shows the current narrowspec entries, one per line. Each line will be prefixed with 'I' or 'X' for included or excluded patterns, respectively.
The narrowspec is comprised of expressions to match remote files and/or directories that should be pulled into your client.  The narrowspec has include and exclude expressions, with excludes always trumping includes: that is, if a file matches an exclude expression, it will be excluded even if it also matches an include expression.  Excluding files that were never included has no effect.
Each included or excluded entry is in the format described by 'hg help patterns'.
The options allow you to add or remove included and excluded expressions.
If --clear is specified, then all previous includes and excludes are DROPPED and replaced by the new ones specified to --addinclude and --addexclude.  If --clear is specified without any further options, the narrowspec will be empty and will not match any files.
If --auto-remove-includes is specified, then those includes that don't match any files modified by currently visible local commits (those not shared by the remote) will be added to the set of explicitly specified includes to remove.
--import-rules accepts a path to a file containing rules, allowing you to add --addinclude, --addexclude rules in bulk. Like the other include and exclude switches, the changes are applied immediately.
--addinclude <VALUE[+]> new paths to include
--removeinclude <VALUE[+]> old paths to no longer include
--auto-remove-includes automatically choose unused includes to remove
--addexclude <VALUE[+]> new paths to exclude
--import-rules <VALUE> import narrowspecs from a file
--removeexclude <VALUE[+]> old paths to no longer exclude
--clear whether to replace the existing narrowspec
--force-delete-local-changes forces deletion of local changes when narrowing
--backup back up local changes when narrowing (default: True)
--update-working-copy update working copy when the store has changed
This extension implements hooks to send email notifications when changesets are sent from or received by the local repository.
First, enable the extension as explained in hg help extensions, and register the hook you want to run. incoming and changegroup hooks are run when changesets are received, while outgoing hooks are for changesets sent to another repository:
[hooks] # one email for each incoming changeset incoming.notify = python:hgext.notify.hook # one email for all incoming changesets changegroup.notify = python:hgext.notify.hook
# one email for all outgoing changesets outgoing.notify = python:hgext.notify.hook
This registers the hooks. To enable notification, subscribers must be assigned to repositories. The [usersubs] section maps multiple repositories to a given recipient. The [reposubs] section maps multiple recipients to a single repository:
[usersubs] # key is subscriber email, value is a comma-separated list of repo patterns user@host = pattern
[reposubs] # key is repo pattern, value is a comma-separated list of subscriber emails pattern = user@host
A pattern is a glob matching the absolute path to a repository, optionally combined with a revset expression. A revset expression, if present, is separated from the glob by a hash. Example:
[reposubs] */widgets#branch(release) = qa-team@example.com
This sends to qa-team@example.com whenever a changeset on the release branch triggers a notification in any repository ending in widgets.
In order to place them under direct user management, [usersubs] and [reposubs] sections may be placed in a separate hgrc file and incorporated by reference:
[notify] config = /path/to/subscriptionsfile
Notifications will not be sent until the notify.test value is set to False; see below.
Notifications content can be tweaked with the following configuration entries:
notify.test If True, print messages to stdout instead of sending them. Default: True.
notify.sources Space-separated list of change sources. Notifications are activated only when a changeset's source is in this list. Sources may be:
changesets received via http or ssh
changesets received via hg pull
changesets received via hg unbundle
changesets sent or received via hg push
changesets sent via hg unbundle
Default: serve.
notify.strip Number of leading slashes to strip from url paths. By default, notifications reference repositories with their absolute path. notify.strip lets you turn them into relative paths. For example, notify.strip=3 will change /long/path/repository into repository. Default: 0.
notify.domain Default email domain for sender or recipients with no explicit domain.  It is also used for the domain part of the Message-Id when using notify.messageidseed.
notify.messageidseed Create deterministic Message-Id headers for the mails based on the seed and the revision identifier of the first commit in the changeset.
notify.style Style file to use when formatting emails.
notify.template Template to use when formatting emails.
notify.incoming Template to use when run as an incoming hook, overriding notify.template.
notify.outgoing Template to use when run as an outgoing hook, overriding notify.template.
notify.changegroup Template to use when running as a changegroup hook, overriding notify.template.
notify.maxdiff Maximum number of diff lines to include in notification email. Set to 0 to disable the diff, or -1 to include all of it. Default: 300.
notify.maxdiffstat Maximum number of diffstat lines to include in notification email. Set to -1 to include all of it. Default: -1.
notify.maxsubject Maximum number of characters in email's subject line. Default: 67.
notify.diffstat Set to True to include a diffstat before diff content. Default: True.
notify.showfunc If set, override diff.showfunc for the diff content. Default: None.
notify.merge If True, send notifications for merge changesets. Default: True.
notify.mbox If set, append mails to this mbox file instead of sending. Default: None.
notify.fromauthor If set, use the committer of the first changeset in a changegroup for the "From" field of the notification mail. If not set, take the user from the pushing repo.  Default: False.
notify.reply-to-predecessor (EXPERIMENTAL) If set and the changeset has a predecessor in the repository, try to thread the notification mail with the predecessor. This adds the "In-Reply-To" header to the notification mail with a reference to the predecessor with the smallest revision number. Mail threads can still be torn, especially when changesets are folded.
This option must  be used in combination with notify.messageidseed.
If set, the following entries will also be used to customize the notifications:
email.from Email From address to use if none can be found in the generated email content.
web.baseurl Root repository URL to combine with repository paths when making references. See also notify.strip.
pager browse command output with an external pager (DEPRECATED)
Forcibly enable paging for individual commands that don't typically request pagination with the attend-<command> option. This setting takes precedence over ignore options and defaults:
[pager] attend-cat = false
The series is started off with a "[PATCH 0 of N]" introduction, which describes the series as a whole.
Each patch email has a Subject line of "[PATCH M of N] ...", using the first line of the changeset description as the subject text. The message contains two or three body parts:
• The changeset description.
• [Optional] The result of running diffstat on the patch.
• The patch itself, as generated by hg export.
Each message refers to the first in the series using the In-Reply-To and References headers, so they will show up as a sequence in threaded mail and news readers, and in mail archives.
To configure other defaults, add a section like this to your configuration file:
[email] from = My Name <my@email> to = recipient1, recipient2, ... cc = cc1, cc2, ... bcc = bcc1, bcc2, ... reply-to = address1, address2, ...
Use [patchbomb] as configuration section name if you need to override global [email] address settings.
Then you can use the hg email command to mail a series of changesets as a patchbomb.
You can also either configure the method option in the email section to be a sendmail compatible mailer or fill out the [smtp] section so that the patchbomb extension can automatically send patchbombs directly from the commandline. See the [email] and [smtp] sections in hgrc(5) for details.
By default, hg email will prompt for a To or CC header if you do not supply one via configuration or the command line.  You can override this to never prompt by configuring an empty value:
[email] cc =
You can control the default inclusion of an introduction message with the patchbomb.intro configuration option. The configuration is always overwritten by command line flags like --intro and --desc:
[patchbomb] intro=auto   # include introduction message if more than 1 patch (default) intro=never  # never include an introduction message intro=always # always include an introduction message
You can specify a template for flags to be added in subject prefixes. Flags specified by --flag option are exported as {flags} keyword:
[patchbomb] flagtemplate = "{separate(' ', ifeq(branch, 'default', '', branch|upper), flags)}"
You can set patchbomb to always ask for confirmation by setting patchbomb.confirm to true.
Commands Change import/export email send changesets by email:
hg email [OPTION]... [DEST]...
By default, diffs are sent in the format generated by hg export, one per message. The series starts with a "[PATCH 0 of N]" introduction, which describes the series as a whole.
Each patch email has a Subject line of "[PATCH M of N] ...", using the first line of the changeset description as the subject text.  The message contains two or three parts. First, the changeset description.
With the -d/--diffstat option, if the diffstat program is installed, the result of running diffstat on the patch is inserted.
Finally, the patch itself, as generated by hg export.
With the -d/--diffstat or --confirm options, you will be presented with a final summary of all messages and asked for confirmation before the messages are sent.
By default the patch is included as text in the email body for easy reviewing. Using the -a/--attach option will instead create an attachment for the patch. With -i/--inline an inline attachment will be created. You can include a patch both as text in the email body and as a regular or an inline attachment by combining the -a/--attach or -i/--inline with the --body option.
With -o/--outgoing, emails will be generated for patches not found in the destination repository (or only those which are ancestors of the specified revisions if any are provided)
With -b/--bundle, changesets are selected as for --outgoing, but a single email containing a binary Mercurial bundle as an attachment will be sent. Use the patchbomb.bundletype config option to control the bundle type as with hg bundle --type.
With -m/--mbox, instead of previewing each patchbomb message in a pager or sending the messages directly, it will create a UNIX mailbox file with the patch emails. This mailbox file can be previewed with any mail user agent which supports UNIX mbox files.
With -n/--test, all steps will run, but mail will not be sent.  You will be prompted for an email recipient address, a subject and an introductory message describing the patches of your patchbomb.  Then when all is done, patchbomb messages are displayed.
In case email sending fails, you will find a backup of your series introductory message in .hg/last-email.txt.
The default behavior of this command can be customized through configuration. (See hg help patchbomb for details)
hg email -r 3000          # send patch 3000 only hg email -r 3000 -r 3001  # send patches 3000 and 3001 hg email -r 3000:3005     # send patches 3000 through 3005 hg email 3000             # send patch 3000 (deprecated)
hg email -o               # send all patches not in default hg email -o DEST          # send all patches not in DEST hg email -o -r 3000       # send all ancestors of 3000 not in default hg email -o -r 3000 DEST  # send all ancestors of 3000 not in DEST
hg email -B feature       # send all ancestors of feature bookmark
hg email -b               # send bundle of all patches not in default hg email -b DEST          # send bundle of all patches not in DEST hg email -b -r 3000       # bundle of all ancestors of 3000 not in default hg email -b -r 3000 DEST  # bundle of all ancestors of 3000 not in DEST
hg email -o -m mbox &&    # generate an mbox file... mutt -R -f mbox         # ... and view it with mutt hg email -o -m mbox &&    # generate an mbox file ... formail -s sendmail \   # ... and use formail to send from the mbox -bm -t < mbox         # ... using sendmail
Before using this command, you will need to enable email in your hgrc. See the [email] section in hgrc(5) for details.
--plain omit hg patch header
-o, --outgoing send changes not found in the target repository
-b, --bundle send changes not in target as a binary bundle
-B,--bookmark <BOOKMARK> send changes only reachable by given bookmark
--bundlename <NAME> name of the bundle attachment file (default: bundle)
-r,--rev <REV[+]> a revision to send
--force run even when remote repository is unrelated (with -b/--bundle)
--base <REV[+]> a base changeset to specify instead of a destination (with -b/--bundle)
--intro send an introduction email for a single patch
--body send patches as inline message text (default)
-a, --attach send patches as attachments
-i, --inline send patches as inline attachments
--bcc <EMAIL[+]> email addresses of blind carbon copy recipients
-c,--cc <EMAIL[+]> email addresses of copy recipients
--confirm ask for confirmation before sending
-d, --diffstat add diffstat output to messages
--date <DATE> use the given date as the sending date
--desc <FILE> use the given file as the series description
-f,--from <EMAIL> email address of sender
-n, --test print messages that would be sent
-m,--mbox <FILE> write messages to mbox file instead of sending them
--reply-to <EMAIL[+]> email addresses replies should be sent to
-s,--subject <TEXT> subject of first message (intro or single patch)
--in-reply-to <MSGID> message identifier to reply to
--flag <FLAG[+]> flags to add in subject prefixes
-t,--to <EMAIL[+]> email addresses of recipients
phabricator simple Phabricator integration (EXPERIMENTAL)
This extension provides a phabsend command which sends a stack of changesets to Phabricator, and a phabread command which prints a stack of revisions in a format suitable for hg import, and a phabupdate command to update statuses in batch.
A "phabstatus" view for hg show is also provided; it displays status information of Phabricator differentials associated with unfinished changesets.
By default, Phabricator requires Test Plan which might prevent some changeset from being sent. The requirement could be disabled by changing differential.require-test-plan-field config server side.
Config:
[phabricator] # Phabricator URL url = https://phab.example.com/
# Repo callsign. If a repo has a URL https://$HOST/diffusion/FOO, then its # callsign is "FOO". callsign = FOO
# curl command to use. If not set (default), use builtin HTTP library to # communicate. If set, use the specified curl command. This could be useful # if you need to specify advanced options that is not easily supported by # the internal library. curlcmd = curl --connect-timeout 2 --retry 3 --silent
# retry failed command N time (default 0). Useful when using the extension # over flakly connection. # # We wait `retry.interval` between each retry, in seconds. # (default 1 second). retry = 3 retry.interval = 10
# the retry option can combine well with the http.timeout one. # # For example to give up on http request after 20 seconds: [http] timeout=20
[auth] example.schemes = https example.prefix = phab.example.com
# API token. Get it from https://$HOST/conduit/login/ example.phabtoken = cli-xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Commands Change import/export phabimport import patches from Phabricator for the specified Differential Revisions:
hg phabimport DREVSPEC... [OPTIONS]
The patches are read and applied starting at the parent of the working directory.
See hg help phabread for how to specify DREVSPEC.
--stack import dependencies as well
--test-vcr <VALUE> Path to a vcr file. If nonexistent, will record a new vcr transcript, otherwise will mock all http requests using the specified vcr file. (ADVANCED)
phabread print patches from Phabricator suitable for importing:
hg phabread DREVSPEC... [OPTIONS]
DREVSPEC could be a Differential Revision identity, like D123, or just the number 123. It could also have common operators like +, -, &, (, ) for complex queries. Prefix : could be used to select a stack.  If multiple DREVSPEC values are given, the result is the union of each individually evaluated value.  No attempt is currently made to reorder the values to run from parent to child.
abandoned, accepted, closed, needsreview, needsrevision could be used to filter patches by status. For performance reason, they only represent a subset of non-status selections and cannot be used alone.
For example, :D6+8-(2+D4) selects a stack up to D6, plus D8 and exclude D2 and D4. :D9 & needsreview selects "Needs Review" revisions in a stack up to D9.
If --stack is given, follow dependencies information and read all patches.  It is equivalent to the : operator.
--stack read dependencies
phabsend upload changesets to Phabricator:
hg phabsend REV [OPTIONS]
If there are multiple revisions specified, they will be send as a stack with a linear dependencies relationship using the order specified by the revset.
For the first time uploading changesets, local tags will be created to maintain the association. After the first time, phabsend will check obsstore and tags information so it can figure out whether to update an existing Differential Revision, or create a new one.
If --amend is set, update commit messages so they have the Differential Revision URL, remove related tags. This is similar to what arcanist will do, and is more desired in author-push workflows. Otherwise, use local tags to record the Differential Revision association.
The --confirm option lets you confirm changesets before sending them. You can also add following to your configuration file to make it default behaviour:
[phabsend] confirm = true
By default, a separate review will be created for each commit that is selected, and will have the same parent/child relationship in Phabricator.  If --fold is set, multiple commits are rolled up into a single review as if diffed from the parent of the first revision to the last.  The commit messages are concatenated in the summary field on Phabricator.
phabsend will check obsstore and the above association to decide whether to update an existing Differential Revision, or create a new one.
-r,--rev <REV[+]> revisions to send
--amend update commit messages (default: True)
--reviewer <VALUE[+]> specify reviewers
--blocker <VALUE[+]> specify blocking reviewers
-m,--comment <VALUE> add a comment to Revisions with new/updated Diffs
--fold combine the revisions into one review
phabupdate update Differential Revision in batch:
hg phabupdate [DREVSPEC...| -r REV...] [OPTIONS]
DREVSPEC selects revisions. See hg help phabread for its usage.
--accept accept revisions
--reject reject revisions
--request-review request review on revisions
--abandon abandon revisions
--reclaim reclaim revisions
--close close revisions
--reopen reopen revisions
--plan-changes plan changes for revisions
--resign resign as a reviewer from revisions
--commandeer commandeer revisions
-m,--comment <VALUE> comment on the last revision
-r,--rev <REV> local revision to update
Uncategorized commands purge command to delete untracked files from the working directory (DEPRECATED)
The functionality of this extension has been included in core Mercurial since version 5.7. Please use hg purge ... instead. hg purge --confirm is now the default, unless the extension is enabled for backward compatibility.
This extension lets you rebase changesets in an existing Mercurial repository.
For more information: https://mercurial-scm.org/wiki/RebaseExtension
Commands Change manipulation rebase move changeset (and descendants) to a different branch:
hg rebase [[-s REV]... | [-b REV]... | [-r REV]...] [-d REV] [OPTION]...