neulab/tldr huggingface dataset:
A template defined in templates section can also be referenced from another template:
$ hg log -r . -T "{rev} {nodedate}"
but be aware that the keywords cannot be overridden by templates. For example, a template defined as templates.rev cannot be referenced as {rev}.
A template defined in templates section may have sub templates which are inserted before/after/between items:
[templates] myjson = ' {dict(rev, node|short)|json}' myjson:docheader = '\{\n' myjson:docfooter = '\n}\n' myjson:separator = ',\n'
Examples Some sample command line templates:
• Format lists, e.g. files:
$ hg log -r 0 --template "files:\n{files % '  {file}\n'}"
• Join the list of files with a ", ":
$ hg log -r 0 --template "files: {join(files, ', ')}\n"
• Join the list of files ending with ".py" with a ", ":
$ hg log -r 0 --template "pythonfiles: {join(files('**.py'), ', ')}\n"
• Separate non-empty arguments by a " ":
$ hg log -r 0 --template "{separate(' ', node, bookmarks, tags}\n"
• Modify each line of a commit description:
$ hg log --template "{splitlines(desc) % '**** {line}\n'}"
• Format date:
$ hg log -r 0 --template "{date(date, '%Y')}\n"
• Display date in UTC:
$ hg log -r 0 --template "{localdate(date, 'UTC')|date}\n"
• Output the description set to a fill-width of 30:
$ hg log -r 0 --template "{fill(desc, 30)}"
• Use a conditional to test for the default branch:
$ hg log -r 0 --template "{ifeq(branch, 'default', 'on the main branch', 'on branch {branch}')}\n"
• Append a newline if not empty:
$ hg tip --template "{if(author, '{author}\n')}"
• Label the output for use with the color extension:
$ hg log -r 0 --template "{label('changeset.{phase}', node|short)}\n"
• Invert the firstline filter, i.e. everything but the first line:
$ hg log -r 0 --template "{sub(r'^.*\n?\n?', '', desc)}\n"
• Display the contents of the 'extra' field, one per line:
$ hg log -r 0 --template "{join(extras, '\n')}\n"
• Mark the active bookmark with '*':
$ hg log --template "{bookmarks % '{bookmark}{ifeq(bookmark, active, '*')} '}\n"
• Find the previous release candidate tag, the distance and changes since the tag:
$ hg log -r . --template "{latesttag('re:^.*-rc$') % '{tag}, {changes}, {distance}'}\n"
• Mark the working copy parent with '@':
$ hg log --template "{ifcontains(rev, revset('.'), '@')}\n"
• Show details of parent revisions:
$ hg log --template "{revset('parents(%d)', rev) % '{desc|firstline}\n'}"
• Show only commit descriptions that start with "template":
$ hg log --template "{startswith('template', firstline(desc))}\n"
• Print the first word of each line of a commit message:
$ hg log --template "{word(0, desc)}\n"
Valid URLs are of the form:
local/filesystem/path[#revision] file://local/filesystem/path[#revision] http://[user[:pass]@]host[:port]/[path][#revision] https://[user[:pass]@]host[:port]/[path][#revision] ssh://[user@]host[:port]/[path][#revision] path://pathname
Paths in the local filesystem can either point to Mercurial repositories or to bundle files (as created by hg bundle or hg incoming --bundle). See also hg help paths.
An optional identifier after # indicates a particular branch, tag, or changeset to use from the remote repository. See also hg help revisions.
Some features, such as pushing to http:// and https:// URLs are only possible if the feature is explicitly enabled on the remote Mercurial server.
Note that the security of HTTPS URLs depends on proper configuration of web.cacerts.
Some notes about using SSH with Mercurial:
• SSH requires an accessible shell account on the destination machine and a copy of hg in the remote path or specified with remotecmd.
• path is relative to the remote user's home directory by default. Use an extra slash at the start of a path to specify an absolute path:
ssh://example.com//tmp/repository
• Mercurial doesn't use its own compression via SSH; the right thing to do is to configure it in your ~/.ssh/config, e.g.:
Host *.mylocalnetwork.example.com Compression no Host * Compression yes
Alternatively specify "ssh -C" as your ssh command in your configuration file or with the --ssh command line option.
These URLs can all be stored in your configuration file with path aliases under the [paths] section like so:
[paths] alias1 = URL1 alias2 = URL2 ...
You can then use the alias for any command that uses a URL (for example hg pull alias1 will be treated as hg pull URL1).
Two path aliases are special because they are used as defaults when you do not provide the URL to a command:
default: When you create a repository with hg clone, the clone command saves the location of the source repository as the new repository's 'default' path. This is then used when you omit path from push- and pull-like commands (including incoming and outgoing).
default-push: The push command will look for a path named 'default-push', and prefer it over 'default' if both are defined.
These alias can also be use in the path:// scheme:
[paths] alias1 = URL1 alias2 = path://alias1 ...
check hg help config.paths for details about the behavior of such "sub-path".
This section contains help for extensions that are distributed together with Mercurial. Help for other extensions is available in the help system.
absorb apply working directory changes to changesets (EXPERIMENTAL)
The absorb extension provides a command to use annotate information to amend modified chunks into the corresponding non-public changesets.
[absorb] # only check 50 recent non-public changesets at most max-stack-size = 50 # whether to add noise to new commits to avoid obsolescence cycle add-noise = 1 # make `amend --correlated` a shortcut to the main command amend-flag = correlated
[color] absorb.description = yellow absorb.node = blue bold absorb.path = bold
Commands Change creation absorb incorporate corrections into the stack of draft changesets:
hg absorb [OPTION] [FILE]...
absorb analyzes each change in your working directory and attempts to amend the changed lines into the changesets in your stack that first introduced those lines.
If absorb cannot find an unambiguous changeset to amend for a change, that change will be left in the working directory, untouched. They can be observed by hg status or hg diff afterwards. In other words, absorb does not write to the working directory.
Changesets outside the revset ::. and not public() and not merge() will not be changed.
Changesets that become empty after applying the changes will be deleted.
By default, absorb will show what it plans to do and prompt for confirmation.  If you are confident that the changes will be absorbed to the correct place, run hg absorb -a to apply the changes immediately.
Returns 0 on success, 1 if all chunks were ignored and nothing amended.
-a, --apply-changes apply changes without prompting for confirmation
-p, --print-changes always print which changesets are modified by which changes
-i, --interactive interactively select which chunks to apply
-e, --edit-lines edit what lines belong to which changesets before commit (EXPERIMENTAL)
acl hooks for controlling repository access
This hook makes it possible to allow or deny write access to given branches and paths of a repository when receiving incoming changesets via pretxnchangegroup and pretxncommit.
The authorization is matched based on the local user name on the system where the hook runs, and not the committer of the original changeset (since the latter is merely informative).
The acl hook is best used along with a restricted shell like hgsh, preventing authenticating users from doing anything other than pushing or pulling. The hook is not safe to use if users have interactive shell access, as they can then disable the hook. Nor is it safe if remote users share an account, because then there is no way to distinguish them.
The order in which access checks are performed is:
1. Deny  list for branches (section acl.deny.branches)
2. Allow list for branches (section acl.allow.branches)
3. Deny  list for paths    (section acl.deny)
4. Allow list for paths    (section acl.allow)
The allow and deny sections take key-value pairs.
Branch-based Access Control Use the acl.deny.branches and acl.allow.branches sections to have branch-based access control. Keys in these sections can be either:
• a branch name, or
• an asterisk, to match any branch;
The corresponding values can be either:
• a comma-separated list containing users and groups, or
• an asterisk, to match anyone;
You can add the "!" prefix to a user or group name to invert the sense of the match.
Path-based Access Control Use the acl.deny and acl.allow sections to have path-based access control. Keys in these sections accept a subtree pattern (with a glob syntax by default). The corresponding values follow the same syntax as the other sections above.
Bookmark-based Access Control Use the acl.deny.bookmarks and acl.allow.bookmarks sections to have bookmark-based access control. Keys in these sections can be either:
• a bookmark name, or
• an asterisk, to match any bookmark;
Note: for interactions between clients and servers using Mercurial 3.6+ a rejection will generally reject the entire push, for interactions involving older clients, the commit transactions will already be accepted, and only the bookmark movement will be rejected.
Groups Group names must be prefixed with an @ symbol. Specifying a group name has the same effect as specifying all the users in that group.
You can define group members in the acl.groups section.  If a group name is not defined there, and Mercurial is running under a Unix-like system, the list of users will be taken from the OS.  Otherwise, an exception will be raised.
Example Configuration [hooks]
# Use this if you want to check access restrictions at commit time pretxncommit.acl = python:hgext.acl.hook
# Use this if you want to check access restrictions for pull, push, # bundle and serve. pretxnchangegroup.acl = python:hgext.acl.hook
[acl] # Allow or deny access for incoming changes only if their source is # listed here, let them pass otherwise. Source is "serve" for all # remote access (http or ssh), "push", "pull" or "bundle" when the # related commands are run locally. # Default: serve sources = serve
[acl.deny.branches]
# Everyone is denied to the frozen branch: frozen-branch = *
# A bad user is denied on all branches: * = bad-user
[acl.allow.branches]
# A few users are allowed on branch-a: branch-a = user-1, user-2, user-3
# Only one user is allowed on branch-b: branch-b = user-1
# The super user is allowed on any branch: * = super-user
# Everyone is allowed on branch-for-tests: branch-for-tests = *
[acl.deny] # This list is checked first. If a match is found, acl.allow is not # checked. All users are granted access if acl.deny is not present. # Format for both lists: glob pattern = user, ..., @group, ...
# To match everyone, use an asterisk for the user: # my/glob/pattern = *
# user6 will not have write access to any file: ** = user6
# Group "hg-denied" will not have write access to any file: ** = @hg-denied
# Nobody will be able to change "DONT-TOUCH-THIS.txt", despite # everyone being able to change all other files. See below. src/main/resources/DONT-TOUCH-THIS.txt = *
[acl.allow] # if acl.allow is not present, all users are allowed by default # empty acl.allow = no users allowed
# User "doc_writer" has write access to any file under the "docs" # folder: docs/** = doc_writer
# User "jack" and group "designers" have write access to any file # under the "images" folder: images/** = jack, @designers
# Everyone (except for "user6" and "@hg-denied" - see acl.deny above) # will have write access to any file under the "resources" folder # (except for 1 file. See acl.deny): src/main/resources/** = *
.hgtags = release_engineer
Examples using the ! prefix Suppose there's a branch that only a given user (or group) should be able to push to, and you don't want to restrict access to any other branch that may be created.
The "!" prefix allows you to prevent anyone except a given user or group to push changesets in a given branch or path.
In the examples below, we will: 1) Deny access to branch "ring" to anyone but user "gollum" 2) Deny access to branch "lake" to anyone but members of the group "hobbit" 3) Deny access to a file to anyone but user "gollum"
[acl.allow.branches] # Empty
# 1) only 'gollum' can commit to branch 'ring'; # 'gollum' and anyone else can still commit to any other branch. ring = !gollum
# 2) only members of the group 'hobbit' can commit to branch 'lake'; # 'hobbit' members and anyone else can still commit to any other branch. lake = !@hobbit
# You can also deny access based on file paths:
[acl.allow] # Empty
[acl.deny] # 3) only 'gollum' can change the file below; # 'gollum' and anyone else can still change any other file. /misty/mountains/cave/ring = !gollum
amend provide the amend command (EXPERIMENTAL)
This extension provides an amend command that is similar to commit --amend but does not prompt an editor.
Commands Change creation amend amend the working copy parent with all or specified outstanding changes:
hg amend [OPTION]... [FILE]...
Similar to hg commit --amend, but reuse the commit message without invoking editor, unless --edit was set.
See hg help commit for more details.
--close-branch mark a branch as closed, hiding it from the branch list
-n,--note <VALUE> store a note on the amend
automv check for unrecorded moves at commit time (EXPERIMENTAL)
This extension checks at commit/amend time if any of the committed files comes from an unrecorded mv.
The threshold at which a file is considered a move can be set with the automv.similarity config option. This option takes a percentage between 0 (disabled) and 100 (files must be identical), the default is 95.
beautifygraph beautify log -G output by using Unicode characters (EXPERIMENTAL)
A terminal with UTF-8 support and monospace narrow text are required.
Logs event information to .hg/blackbox.log to help debug and diagnose problems.  The events that get logged can be configured via the blackbox.track and blackbox.ignore config keys.
[blackbox] track = * ignore = pythonhook # dirty is *EXPENSIVE* (slow); # each log entry indicates `+` if the repository is dirty, like :hg:`id`. dirty = True # record the source of log messages logsource = True
[blackbox] track = command, commandfinish, commandexception, exthook, pythonhook
[blackbox] track = incoming
[blackbox] # limit the size of a log file maxsize = 1.5 MB # rotate up to N log files when the current one gets too big maxfiles = 3
[blackbox] # Include nanoseconds in log entries with %f (see Python function # datetime.datetime.strftime) date-format = %Y-%m-%d @ %H:%M:%S.%f
Commands Repository maintenance blackbox view the recent repository events:
hg blackbox [OPTION]...
view the recent repository events
-l,--limit <VALUE> the number of events to show (default: 10)
bookflow implements bookmark-based branching (EXPERIMENTAL)
• Disables creation of new branches (config: enable_branches=False).
• Requires an active bookmark on commit (config: require_bookmark=True).
• Doesn't move the active bookmark on update, only on commit.
• Requires '--rev' for moving an existing bookmark.
• Protects special bookmarks (config: protect=@).
flow related commands
hg book NAME create a new bookmark
hg book NAME -r REV move bookmark to revision (fast-forward)
hg up|co NAME switch to bookmark
hg push -B . push active bookmark
This hook extension adds comments on bugs in Bugzilla when changesets that refer to bugs by Bugzilla ID are seen. The comment is formatted using the Mercurial template mechanism.
The bug references can optionally include an update for Bugzilla of the hours spent working on the bug. Bugs can also be marked fixed.
Four basic modes of access to Bugzilla are provided:
1. Access via the Bugzilla REST-API. Requires bugzilla 5.0 or later.
2. Access via the Bugzilla XMLRPC interface. Requires Bugzilla 3.4 or later.
3. Check data via the Bugzilla XMLRPC interface and submit bug change via email to Bugzilla email interface. Requires Bugzilla 3.4 or later.
4. Writing directly to the Bugzilla database. Only Bugzilla installations using MySQL are supported. Requires Python MySQLdb.
Writing directly to the database is susceptible to schema changes, and relies on a Bugzilla contrib script to send out bug change notification emails. This script runs as the user running Mercurial, must be run on the host with the Bugzilla install, and requires permission to read Bugzilla configuration details and the necessary MySQL user and password to have full access rights to the Bugzilla database. For these reasons this access mode is now considered deprecated, and will not be updated for new Bugzilla versions going forward. Only adding comments is supported in this access mode.
Access via XMLRPC needs a Bugzilla username and password to be specified in the configuration. Comments are added under that username. Since the configuration must be readable by all Mercurial users, it is recommended that the rights of that user are restricted in Bugzilla to the minimum necessary to add comments. Marking bugs fixed requires Bugzilla 4.0 and later.
Access via XMLRPC/email uses XMLRPC to query Bugzilla, but sends email to the Bugzilla email interface to submit comments to bugs.  The From: address in the email is set to the email address of the Mercurial user, so the comment appears to come from the Mercurial user. In the event that the Mercurial user email is not recognized by Bugzilla as a Bugzilla user, the email associated with the Bugzilla username used to log into Bugzilla is used instead as the source of the comment. Marking bugs fixed works on all supported Bugzilla versions.
Access via the REST-API needs either a Bugzilla username and password or an apikey specified in the configuration. Comments are made under the given username or the user associated with the apikey in Bugzilla.
Configuration items common to all access modes:
bugzilla.version The access type to use. Values recognized are:
Bugzilla REST-API, Bugzilla 5.0 and later.
Bugzilla XMLRPC interface.
xmlrpc+email
Bugzilla XMLRPC and email interfaces.
MySQL access, Bugzilla 3.0 and later.
MySQL access, Bugzilla 2.18 and up to but not including 3.0.
MySQL access, Bugzilla 2.16 and up to but not including 2.18.
bugzilla.regexp Regular expression to match bug IDs for update in changeset commit message.  It must contain one "()" named group <ids> containing the bug IDs separated by non-digit characters. It may also contain a named group <hours> with a floating-point number giving the hours worked on the bug. If no named groups are present, the first "()" group is assumed to contain the bug IDs, and work time is not updated. The default expression matches Bug 1234, Bug no. 1234, Bug number 1234, Bugs 1234,5678, Bug 1234 and 5678 and variations thereof, followed by an hours number prefixed by h or hours, e.g. hours 1.5. Matching is case insensitive.
bugzilla.fixregexp Regular expression to match bug IDs for marking fixed in changeset commit message. This must contain a "()" named group <ids>` containing the bug IDs separated by non-digit characters. It may also contain a named group ``<hours> with a floating-point number giving the hours worked on the bug. If no named groups are present, the first "()" group is assumed to contain the bug IDs, and work time is not updated. The default expression matches Fixes 1234, Fixes bug 1234, Fixes bugs 1234,5678, Fixes 1234 and 5678 and variations thereof, followed by an hours number prefixed by h or hours, e.g. hours 1.5. Matching is case insensitive.
bugzilla.fixstatus The status to set a bug to when marking fixed. Default RESOLVED.
bugzilla.fixresolution The resolution to set a bug to when marking fixed. Default FIXED.
bugzilla.style The style file to use when formatting comments.
bugzilla.template Template to use when formatting comments. Overrides style if specified. In addition to the usual Mercurial keywords, the extension specifies:
{bug}
The Bugzilla bug ID.
{root}
The full pathname of the Mercurial repository.
{webroot}
Stripped pathname of the Mercurial repository.
{hgweb}
Base URL for browsing Mercurial repositories.
Default changeset {node|short} in repo {root} refers to bug {bug}.\ndetails:\n\t{desc|tabindent}
bugzilla.strip The number of path separator characters to strip from the front of the Mercurial repository path ({root} in templates) to produce {webroot}. For example, a repository with {root} /var/local/my-project with a strip of 2 gives a value for {webroot} of my-project. Default 0.
web.baseurl Base URL for browsing Mercurial repositories. Referenced from templates as {hgweb}.
Configuration items common to XMLRPC+email and MySQL access modes:
bugzilla.usermap Path of file containing Mercurial committer email to Bugzilla user email mappings. If specified, the file should contain one mapping per line:
committer = Bugzilla user
See also the [usermap] section.
The [usermap] section is used to specify mappings of Mercurial committer email to Bugzilla user email. See also bugzilla.usermap.  Contains entries of the form committer = Bugzilla user.
XMLRPC and REST-API access mode configuration:
bugzilla.bzurl The base URL for the Bugzilla installation.  Default http://localhost/bugzilla.
bugzilla.user The username to use to log into Bugzilla via XMLRPC. Default bugs.
bugzilla.password The password for Bugzilla login.
REST-API access mode uses the options listed above as well as:
bugzilla.apikey An apikey generated on the Bugzilla instance for api access. Using an apikey removes the need to store the user and password options.
XMLRPC+email access mode uses the XMLRPC access mode configuration items, and also:
bugzilla.bzemail The Bugzilla email address.
In addition, the Mercurial email settings must be configured. See the documentation in hgrc(5), sections [email] and [smtp].
MySQL access mode configuration:
bugzilla.host Hostname of the MySQL server holding the Bugzilla database. Default localhost.
bugzilla.db Name of the Bugzilla database in MySQL. Default bugs.
bugzilla.user Username to use to access MySQL server. Default bugs.
bugzilla.password Password to use to access MySQL server.
bugzilla.timeout Database connection timeout (seconds). Default 5.
bugzilla.bzuser Fallback Bugzilla user name to record comments with, if changeset committer cannot be found as a Bugzilla user.
bugzilla.bzdir Bugzilla install directory. Used by default notify. Default /var/www/html/bugzilla.
bugzilla.notify The command to run to get Bugzilla to send bug change notification emails. Substitutes from a map with 3 keys, bzdir, id (bug id) and user (committer bugzilla email). Default depends on version; from 2.18 it is "cd %(bzdir)s && perl -T contrib/sendbugmail.pl %(id)s %(user)s".
Activating the extension:
[extensions] bugzilla =
[hooks] # run bugzilla hook on every change pulled or pushed in here incoming.bugzilla = python:hgext.bugzilla.hook
Example configurations:
XMLRPC example configuration. This uses the Bugzilla at http://my-project.org/bugzilla, logging in as user bugmail@my-project.org with password plugh. It is used with a collection of Mercurial repositories in /var/local/hg/repos/, with a web interface at http://my-project.org/hg.
[bugzilla] bzurl=http://my-project.org/bugzilla user=bugmail@my-project.org password=plugh version=xmlrpc template=Changeset {node|short} in {root|basename}. {hgweb}/{webroot}/rev/{node|short}\n {desc}\n strip=5
[web] baseurl=http://my-project.org/hg
XMLRPC+email example configuration. This uses the Bugzilla at http://my-project.org/bugzilla, logging in as user bugmail@my-project.org with password plugh. It is used with a collection of Mercurial repositories in /var/local/hg/repos/, with a web interface at http://my-project.org/hg. Bug comments are sent to the Bugzilla email address bugzilla@my-project.org.
[bugzilla] bzurl=http://my-project.org/bugzilla user=bugmail@my-project.org password=plugh version=xmlrpc+email bzemail=bugzilla@my-project.org template=Changeset {node|short} in {root|basename}. {hgweb}/{webroot}/rev/{node|short}\n {desc}\n strip=5
[usermap] user@emaildomain.com=user.name@bugzilladomain.com
MySQL example configuration. This has a local Bugzilla 3.2 installation in /opt/bugzilla-3.2. The MySQL database is on localhost, the Bugzilla database name is bugs and MySQL is accessed with MySQL username bugs password XYZZY. It is used with a collection of Mercurial repositories in /var/local/hg/repos/, with a web interface at http://my-project.org/hg.
[bugzilla] host=localhost password=XYZZY version=3.0 bzuser=unknown@domain.com bzdir=/opt/bugzilla-3.2 template=Changeset {node|short} in {root|basename}. {hgweb}/{webroot}/rev/{node|short}\n {desc}\n strip=5
All the above add a comment to the Bugzilla bug record of the form:
Changeset 3b16791d6642 in repository-name. http://my-project.org/hg/repository-name/rev/3b16791d6642
Changeset commit comment. Bug 1234.
The censor command instructs Mercurial to erase all content of a file at a given revision without updating the changeset hash. This allows existing history to remain valid while preventing future clones/pulls from receiving the erased data.
Typical uses for censor are due to security or legal requirements, including:
* Passwords, private keys, cryptographic material * Licensed data/code/libraries for which the license has expired * Personally Identifiable Information or other private data
Censored nodes can interrupt mercurial's typical operation whenever the excised data needs to be materialized. Some commands, like hg cat/hg revert, simply fail when asked to produce censored data. Others, like hg verify and hg update, must be capable of tolerating censored data to continue to function in a meaningful way. Such commands only tolerate censored file revisions if they are allowed by the "censor.policy=ignore" config option.
A few informative commands such as hg grep will unconditionally ignore censored data and merely report that it was encountered.
Commands Repository maintenance censor hg censor -r REV [-t TEXT] [FILE]
-r,--rev <REV> censor file from specified revision
-t,--tombstone <TEXT> replacement tombstone data
children command to display child changesets (DEPRECATED)
This extension is deprecated. You should use hg log -r "children(REV)" instead.
Commands Change navigation children show the children of the given or working directory revision:
hg children [-r REV] [FILE]
Print the children of the working directory's revisions. If a revision is given via -r/--rev, the children of that revision will be printed. If a file argument is given, revision in which the file was last changed (after the working directory revision or the argument to --rev if given) is printed.
Please use hg log instead:
hg children => hg log -r "children(.)" hg children -r REV => hg log -r "children(REV)"
See hg help log and hg help revsets.children.
-r,--rev <REV> show children of the specified revision (default: .)
churn command to display statistics about repository history
Commands Repository maintenance churn histogram of changes to the repository:
hg churn [-d DATE] [-r REV] [--aliases FILE] [FILE]
This command will display a histogram representing the number of changed lines or revisions, grouped according to the given template. The default template will group changes by author.  The --dateformat option may be used to group the results by date instead.
Statistics are based on the number of changed lines, or alternatively the number of matching revisions if the --changesets option is specified.
# display count of changed lines for every committer hg churn -T "{author|email}"
# display daily activity graph hg churn -f "%H" -s -c
# display activity of developers by month hg churn -f "%Y-%m" -s -c
# display count of lines changed in every year hg churn -f "%Y" -s
# display count of lines changed in a time range hg churn -d "2020-04 to 2020-09"
It is possible to map alternate email addresses to a main address by providing a file using the following format:
<alias email> = <actual email>
Such a file may be specified with the --aliases option, otherwise a .hgchurn file will be looked for in the working directory root.  Aliases will be split from the rightmost "=".
-r,--rev <REV[+]> count rate for the specified revision or revset
-d,--date <DATE> count rate for revisions matching date spec
-t,--oldtemplate <TEMPLATE> template to group changesets (DEPRECATED)
-T,--template <TEMPLATE> template to group changesets (default: {author|email})
-f,--dateformat <FORMAT> strftime-compatible format for grouping by date
-c, --changesets count rate by number of changesets
-s, --sort sort by key (default: sort by count)
--diffstat display added/removed lines separately
--aliases <FILE> file with email aliases
"clonebundles" is a server-side extension used to advertise the existence of pre-generated, externally hosted bundle files to clients that are cloning so that cloning can be faster, more reliable, and require less resources on the server. "pullbundles" is a related feature for sending pre-generated bundle files to clients as part of pull operations.
Cloning can be a CPU and I/O intensive operation on servers. Traditionally, the server, in response to a client's request to clone, dynamically generates a bundle containing the entire repository content and sends it to the client.  There is no caching on the server and the server will have to redundantly generate the same outgoing bundle in response to each clone request. For servers with large repositories or with high clone volume, the load from clones can make scaling the server challenging and costly.
This extension provides server operators the ability to offload potentially expensive clone load to an external service. Pre-generated bundles also allow using more CPU intensive compression, reducing the effective bandwidth requirements.
Here's how clone bundles work:
1. A server operator establishes a mechanism for making bundle files available on a hosting service where Mercurial clients can fetch them.
2. A manifest file listing available bundle URLs and some optional metadata is added to the Mercurial repository on the server.
3. A client initiates a clone against a clone bundles aware server.
4. The client sees the server is advertising clone bundles and fetches the manifest listing available bundles.
5. The client filters and sorts the available bundles based on what it supports and prefers.
6. The client downloads and applies an available bundle from the server-specified URL.
7. The client reconnects to the original server and performs the equivalent of hg pull to retrieve all repository data not in the bundle. (The repository could have been updated between when the bundle was created and when the client started the clone.) This may use "pullbundles".
Instead of the server generating full repository bundles for every clone request, it generates full bundles once and they are subsequently reused to bootstrap new clones. The server may still transfer data at clone time.  However, this is only data that has been added/changed since the bundle was created. For large, established repositories, this can reduce server load for clones to less than 1% of original.
Here's how pullbundles work:
1. A manifest file listing available bundles and describing the revisions is added to the Mercurial repository on the server.
2. A new-enough client informs the server that it supports partial pulls and initiates a pull.
3. If the server has pull bundles enabled and sees the client advertising partial pulls, it checks for a matching pull bundle in the manifest. A bundle matches if the format is supported by the client, the client has the required revisions already and needs something from the bundle.
4. If there is at least one matching bundle, the server sends it to the client.
5. The client applies the bundle and notices that the server reply was incomplete. It initiates another pull.
To work, this extension requires the following of server operators:
• Generating bundle files of repository content (typically periodically, such as once per day).
• Clone bundles: A file server that clients have network access to and that Python knows how to talk to through its normal URL handling facility (typically an HTTP/HTTPS server).
• A process for keeping the bundles manifest in sync with available bundle files.
Strictly speaking, using a static file hosting server isn't required: a server operator could use a dynamic service for retrieving bundle data. However, static file hosting services are simple and scalable and should be sufficient for most needs.
Bundle files can be generated with the hg bundle command. Typically hg bundle --all is used to produce a bundle of the entire repository.
hg debugcreatestreamclonebundle can be used to produce a special streaming clonebundle. These are bundle files that are extremely efficient to produce and consume (read: fast). However, they are larger than traditional bundle formats and require that clients support the exact set of repository data store formats in use by the repository that created them.  Typically, a newer server can serve data that is compatible with older clients.  However, streaming clone bundles don't have this guarantee. Server operators need to be aware that newer versions of Mercurial may produce streaming clone bundles incompatible with older Mercurial versions.
A server operator is responsible for creating a .hg/clonebundles.manifest file containing the list of available bundle files suitable for seeding clones. If this file does not exist, the repository will not advertise the existence of clone bundles when clients connect. For pull bundles, .hg/pullbundles.manifest is used.
The manifest file contains a newline (n) delimited list of entries.
Each line in this file defines an available bundle. Lines have the format:
<URL> [<key>=<value>[ <key>=<value>]]
That is, a URL followed by an optional, space-delimited list of key=value pairs describing additional properties of this bundle. Both keys and values are URI encoded.
For pull bundles, the URL is a path under the .hg directory of the repository.
Keys in UPPERCASE are reserved for use by Mercurial and are defined below.  All non-uppercase keys can be used by site installations. An example use for custom properties is to use the datacenter attribute to define which data center a file is hosted in. Clients could then prefer a server in the data center closest to them.
The following reserved keys are currently defined:
BUNDLESPEC A "bundle specification" string that describes the type of the bundle.
These are string values that are accepted by the "--type" argument of hg bundle.
The values are parsed in strict mode, which means they must be of the "<compression>-<type>" form. See mercurial.exchange.parsebundlespec() for more details.
hg debugbundle --spec can be used to print the bundle specification string for a bundle file. The output of this command can be used verbatim for the value of BUNDLESPEC (it is already escaped).
Clients will automatically filter out specifications that are unknown or unsupported so they won't attempt to download something that likely won't apply.
The actual value doesn't impact client behavior beyond filtering: clients will still sniff the bundle type from the header of downloaded files.
Use of this key is highly recommended, as it allows clients to easily skip unsupported bundles. If this key is not defined, an old client may attempt to apply a bundle that it is incapable of reading.
REQUIRESNI Whether Server Name Indication (SNI) is required to connect to the URL.  SNI allows servers to use multiple certificates on the same IP. It is somewhat common in CDNs and other hosting providers. Older Python versions do not support SNI. Defining this attribute enables clients with older Python versions to filter this entry without experiencing an opaque SSL failure at connection time.
If this is defined, it is important to advertise a non-SNI fallback URL or clients running old Python releases may not be able to clone with the clonebundles facility.
Value should be "true".
REQUIREDRAM Value specifies expected memory requirements to decode the payload.  Values can have suffixes for common bytes sizes. e.g. "64MB".
This key is often used with zstd-compressed bundles using a high compression level / window size, which can require 100+ MB of memory to decode.
heads  Used for pull bundles. This contains the ; separated changeset hashes of the heads of the bundle content.
bases  Used for pull bundles. This contains the ; separated changeset hashes of the roots of the bundle content. This can be skipped if the bundle was created without --base.
Manifests can contain multiple entries. Assuming metadata is defined, clients will filter entries from the manifest that they don't support. The remaining entries are optionally sorted by client preferences (ui.clonebundleprefers config option). The client then attempts to fetch the bundle at the first URL in the remaining list.
Errors when downloading a bundle will fail the entire clone operation: clients do not automatically fall back to a traditional clone. The reason for this is that if a server is using clone bundles, it is probably doing so because the feature is necessary to help it scale. In other words, there is an assumption that clone load will be offloaded to another service and that the Mercurial server isn't responsible for serving this clone load.  If that other service experiences issues and clients start mass falling back to the original Mercurial server, the added clone load could overwhelm the server due to unexpected load and effectively take it offline. Not having clients automatically fall back to cloning from the original server mitigates this scenario.
Because there is no automatic Mercurial server fallback on failure of the bundle hosting service, it is important for server operators to view the bundle hosting service as an extension of the Mercurial server in terms of availability and service level agreements: if the bundle hosting service goes down, so does the ability for clients to clone. Note: clients will see a message informing them how to bypass the clone bundles facility when a failure occurs. So server operators should prepare for some people to follow these instructions when a failure occurs, thus driving more load to the original Mercurial server when the bundle hosting service fails.
Commands Change manipulation close-head close the given head revisions:
hg close-head [OPTION]... [REV]...
This is equivalent to checking out each revision in a clean tree and running hg commit --close-branch, except that it doesn't change the working directory.
The commit message must be specified with -l or -m.
-r,--rev <REV[+]> revision to check
aliases: close-heads
commitextras adds a new flag extras to commit (ADVANCED)
Commands Uncategorized commands convert convert a foreign SCM repository to a Mercurial one.:
hg convert [OPTION]... SOURCE [DEST [REVMAP]]
Accepted source formats [identifiers]:
• Mercurial [hg]
• CVS [cvs]
• Darcs [darcs]
• git [git]
• Subversion [svn]
• Monotone [mtn]
• GNU Arch [gnuarch]
• Bazaar [bzr]
• Perforce [p4]
Accepted destination formats [identifiers]:
• Subversion [svn] (history on branches is not preserved)
If no revision is given, all revisions will be converted.  Otherwise, convert will only import up to the named revision (given in a format understood by the source).
If no destination directory name is specified, it defaults to the basename of the source with -hg appended. If the destination repository doesn't exist, it will be created.
By default, all sources except Mercurial will use --branchsort. Mercurial uses --sourcesort to preserve original revision numbers order. Sort modes have the following effects:
--branchsort convert from parent to child revision when possible, which means branches are usually converted one after the other. It generates more compact repositories.
--datesort sort revisions by date. Converted repositories have good-looking changelogs but are often an order of magnitude larger than the same ones generated by --branchsort.
--sourcesort try to preserve source revisions order, only supported by Mercurial sources.
--closesort try to move closed revisions as close as possible to parent branches, only supported by Mercurial sources.
If REVMAP isn't given, it will be put in a default location (<dest>/.hg/shamap by default). The REVMAP is a simple text file that maps each source commit ID to the destination ID for that revision, like so:
<source ID> <destination ID>
If the file doesn't exist, it's automatically created. It's updated on each commit copied, so hg convert can be interrupted and can be run repeatedly to copy new commits.
The authormap is a simple text file that maps each source commit author to a destination commit author. It is handy for source SCMs that use unix logins to identify authors (e.g.: CVS). One line per author mapping and the line format is:
source author = destination author
Empty lines and lines starting with a # are ignored.
The filemap is a file that allows filtering and remapping of files and directories. Each line can contain one of the following directives:
include path/to/file-or-dir
exclude path/to/file-or-dir
rename path/to/source path/to/destination
Comment lines start with #. A specified path matches if it equals the full relative name of a file or one of its parent directories. The include or exclude directive with the longest matching path applies, so line order does not matter.
The include directive causes a file, or all files under a directory, to be included in the destination repository. The default if there are no include statements is to include everything.  If there are any include statements, nothing else is included.  The exclude directive causes files or directories to be omitted. The rename directive renames a file or directory if it is converted. To rename from a subdirectory into the root of the repository, use . as the path to rename to.
--full will make sure the converted changesets contain exactly the right files with the right content. It will make a full conversion of all files, not just the ones that have changed. Files that already are correct will not be changed. This can be used to apply filemap changes when converting incrementally. This is currently only supported for Mercurial and Subversion.
The splicemap is a file that allows insertion of synthetic history, letting you specify the parents of a revision. This is useful if you want to e.g. give a Subversion merge two parents, or graft two disconnected series of history together. Each entry contains a key, followed by a space, followed by one or two comma-separated values:
key parent1, parent2
The key is the revision ID in the source revision control system whose parents should be modified (same format as a key in .hg/shamap). The values are the revision IDs (in either the source or destination revision control system) that should be used as the new parents for that node. For example, if you have merged "release-1.0" into "trunk", then you should specify the revision on "trunk" as the first parent and the one on the "release-1.0" branch as the second.
The branchmap is a file that allows you to rename a branch when it is being brought in from whatever external repository. When used in conjunction with a splicemap, it allows for a powerful combination to help fix even the most badly mismanaged repositories and turn them into nicely structured Mercurial repositories. The branchmap contains lines of the form:
original_branch_name new_branch_name
where "original_branch_name" is the name of the branch in the source repository, and "new_branch_name" is the name of the branch is the destination repository. No whitespace is allowed in the new branch name. This can be used to (for instance) move code in one repository from "default" to a named branch.
Mercurial Source The Mercurial source recognizes the following configuration options, which you can set on the command line with --config:
convert.hg.ignoreerrors ignore integrity errors when reading.  Use it to fix Mercurial repositories with missing revlogs, by converting from and to Mercurial. Default is False.
convert.hg.saverev store original revision ID in changeset (forces target IDs to change). It takes a boolean argument and defaults to False.
convert.hg.startrev specify the initial Mercurial revision.  The default is 0.
convert.hg.revs revset specifying the source revisions to convert.
Bazaar Source The following options can be used with --config:
convert.bzr.saverev whether to store the original Bazaar commit ID in the metadata of the destination commit. The default is True.
CVS Source CVS source will use a sandbox (i.e. a checked-out copy) from CVS to indicate the starting point of what will be converted. Direct access to the repository files is not needed, unless of course the repository is :local:. The conversion uses the top level directory in the sandbox to find the CVS repository, and then uses CVS rlog commands to find files to convert. This means that unless a filemap is given, all files under the starting directory will be converted, and that any directory reorganization in the CVS sandbox is ignored.
The following options can be used with --config:
convert.cvsps.cache Set to False to disable remote log caching, for testing and debugging purposes. Default is True.
convert.cvsps.fuzz Specify the maximum time (in seconds) that is allowed between commits with identical user and log message in a single changeset. When very large files were checked in as part of a changeset then the default may not be long enough.  The default is 60.
convert.cvsps.logencoding Specify encoding name to be used for transcoding CVS log messages. Multiple encoding names can be specified as a list (see hg help config.Syntax), but only the first acceptable encoding in the list is used per CVS log entries. This transcoding is executed before cvslog hook below.
convert.cvsps.mergeto Specify a regular expression to which commit log messages are matched. If a match occurs, then the conversion process will insert a dummy revision merging the branch on which this log message occurs to the branch indicated in the regex. Default is {{mergetobranch ([-\w]+)}}
convert.cvsps.mergefrom Specify a regular expression to which commit log messages are matched. If a match occurs, then the conversion process will add the most recent revision on the branch indicated in the regex as the second parent of the changeset. Default is {{mergefrombranch ([-\w]+)}}
convert.localtimezone use local time (as determined by the TZ environment variable) for changeset date/times. The default is False (use UTC).
hooks.cvslog Specify a Python function to be called at the end of gathering the CVS log. The function is passed a list with the log entries, and can modify the entries in-place, or add or delete them.
hooks.cvschangesets Specify a Python function to be called after the changesets are calculated from the CVS log. The function is passed a list with the changeset entries, and can modify the changesets in-place, or add or delete them.
An additional "debugcvsps" Mercurial command allows the builtin changeset merging code to be run without doing a conversion. Its parameters and output are similar to that of cvsps 2.1. Please see the command help for more details.
Subversion Source Subversion source detects classical trunk/branches/tags layouts.  By default, the supplied svn://repo/path/ source URL is converted as a single branch. If svn://repo/path/trunk exists it replaces the default branch. If svn://repo/path/branches exists, its subdirectories are listed as possible branches. If svn://repo/path/tags exists, it is looked for tags referencing converted branches. Default trunk, branches and tags values can be overridden with following options. Set them to paths relative to the source URL, or leave them blank to disable auto detection.
The following options can be set with --config:
convert.svn.branches specify the directory containing branches.  The default is branches.
convert.svn.tags specify the directory containing tags. The default is tags.
convert.svn.trunk specify the name of the trunk branch. The default is trunk.
Source history can be retrieved starting at a specific revision, instead of being integrally converted. Only single branch conversions are supported.
convert.svn.startrev specify start Subversion revision number.  The default is 0.
Git Source The Git importer converts commits from all reachable branches (refs in refs/heads) and remotes (refs in refs/remotes) to Mercurial.  Branches are converted to bookmarks with the same name, with the leading 'refs/heads' stripped. Git submodules are converted to Git subrepos in Mercurial.