neulab/tldr huggingface dataset:
convert.git.similarity specify how similar files modified in a commit must be to be imported as renames or copies, as a percentage between 0 (disabled) and 100 (files must be identical). For example, 90 means that a delete/add pair will be imported as a rename if more than 90% of the file hasn't changed. The default is 50.
convert.git.findcopiesharder while detecting copies, look at all files in the working copy instead of just changed ones. This is very expensive for large projects, and is only effective when convert.git.similarity is greater than 0. The default is False.
convert.git.renamelimit perform rename and copy detection up to this many changed files in a commit. Increasing this will make rename and copy detection more accurate but will significantly slow down computation on large projects. The option is only relevant if convert.git.similarity is greater than 0. The default is 400.
convert.git.committeractions list of actions to take when processing author and committer values.
Git commits have separate author (who wrote the commit) and committer (who applied the commit) fields. Not all destinations support separate author and committer fields (including Mercurial). This config option controls what to do with these author and committer fields during conversion.
A value of messagedifferent will append a committer: ...  line to the commit message if the Git committer is different from the author. The prefix of that line can be specified using the syntax messagedifferent=<prefix>. e.g. messagedifferent=git-committer:. When a prefix is specified, a space will always be inserted between the prefix and the value.
messagealways behaves like messagedifferent except it will always result in a committer: ... line being appended to the commit message. This value is mutually exclusive with messagedifferent.
dropcommitter will remove references to the committer. Only references to the author will remain. Actions that add references to the committer will have no effect when this is set.
replaceauthor will replace the value of the author field with the committer. Other actions that add references to the committer will still take effect when this is set.
The default is messagedifferent.
convert.git.extrakeys list of extra keys from commit metadata to copy to the destination. Some Git repositories store extra metadata in commits.  By default, this non-default metadata will be lost during conversion.  Setting this config option can retain that metadata. Some built-in keys such as parent and branch are not allowed to be copied.
convert.git.remoteprefix remote refs are converted as bookmarks with convert.git.remoteprefix as a prefix followed by a /. The default is 'remote'.
convert.git.saverev whether to store the original Git commit ID in the metadata of the destination commit. The default is True.
convert.git.skipsubmodules does not convert root level .gitmodules files or files with 160000 mode indicating a submodule. Default is False.
Perforce Source The Perforce (P4) importer can be given a p4 depot path or a client specification as source. It will convert all files in the source to a flat Mercurial repository, ignoring labels, branches and integrations. Note that when a depot path is given you then usually should specify a target directory, because otherwise the target may be named ...-hg.
convert.p4.encoding specify the encoding to use when decoding standard output of the Perforce command line tool. The default is default system encoding.
convert.p4.startrev specify initial Perforce revision (a Perforce changelist number).
Mercurial Destination The Mercurial destination will recognize Mercurial subrepositories in the destination directory, and update the .hgsubstate file automatically if the destination subrepositories contain the <dest>/<sub>/.hg/shamap file. Converting a repository with subrepositories requires converting a single repository at a time, from the bottom up.
An example showing how to convert a repository with subrepositories:
# so convert knows the type when it sees a non empty destination $ hg init converted
$ hg convert orig/sub1 converted/sub1 $ hg convert orig/sub2 converted/sub2 $ hg convert orig converted
convert.hg.clonebranches dispatch source branches in separate clones. The default is False.
convert.hg.tagsbranch branch name for tag revisions, defaults to default.
convert.hg.usebranchnames preserve branch names. The default is True.
convert.hg.sourcename records the given string as a 'convert_source' extra value on each commit made in the target repository. The default is None.
convert.hg.preserve-hash only works with mercurial sources. Make convert prevent performance improvement to the list of modified files in commits when such an improvement would cause the hash of a commit to change.  The default is False.
All Destinations All destination types accept the following options:
convert.skiptags does not convert tags from the source repo to the target repo. The default is False.
Subversion Destination Original commit dates are not preserved by default.
convert.svn.dangerous-set-commit-dates preserve original commit dates, forcefully setting svn:date revision properties. This option is DANGEROUS and may break some subversion functionality for the resulting repository (e.g. filtering revisions with date ranges in svn log), as original commit dates are not guaranteed to be monotonically increasing.
For commit dates setting to work destination repository must have pre-revprop-change hook configured to allow setting of svn:date revision properties. See Subversion documentation for more details.
--authors <FILE> username mapping filename (DEPRECATED) (use --authormap instead)
-s,--source-type <TYPE> source repository type
-d,--dest-type <TYPE> destination repository type
-r,--rev <REV[+]> import up to source revision REV
-A,--authormap <FILE> remap usernames using this file
--filemap <FILE> remap file names using contents of file
--full apply filemap changes by converting all files again
--splicemap <FILE> splice synthesized history into place
--branchmap <FILE> change branch names while converting
--branchsort try to sort changesets by branches
--datesort try to sort changesets by date
--sourcesort preserve source changesets order
--closesort try to reorder closed revisions
eol automatically manage newlines in repository files
This extension allows you to manage the type of line endings (CRLF or LF) that are used in the repository and in the local working directory. That way you can get CRLF line endings on Windows and LF on Unix/Mac, thereby letting everybody use their OS native line endings.
The extension reads its configuration from a versioned .hgeol configuration file found in the root of the working directory. The .hgeol file use the same syntax as all other Mercurial configuration files. It uses two sections, [patterns] and [repository].
The [patterns] section specifies how line endings should be converted between the working directory and the repository. The format is specified by a file pattern. The first match is used, so put more specific patterns first. The available line endings are LF, CRLF, and BIN.
Files with the declared format of CRLF or LF are always checked out and stored in the repository in that format and files declared to be binary (BIN) are left unchanged. Additionally, native is an alias for checking out in the platform's default line ending: LF on Unix (including Mac OS X) and CRLF on Windows. Note that BIN (do nothing to line endings) is Mercurial's default behavior; it is only needed if you need to override a later, more general pattern.
The optional [repository] section specifies the line endings to use for files stored in the repository. It has a single setting, native, which determines the storage line endings for files declared as native in the [patterns] section. It can be set to LF or CRLF. The default is LF. For example, this means that on Windows, files configured as native (CRLF by default) will be converted to LF when stored in the repository. Files declared as LF, CRLF, or BIN in the [patterns] section are always stored as-is in the repository.
Example versioned .hgeol file:
[patterns] **.py = native **.vcproj = CRLF **.txt = native Makefile = LF **.jpg = BIN
[repository] native = LF
Note   The rules will first apply when files are touched in the working directory, e.g. by updating to null and back to tip to touch all files.
The extension uses an optional [eol] section read from both the normal Mercurial configuration files and the .hgeol file, with the latter overriding the former. You can use that section to control the overall behavior. There are three settings:
• eol.native (default os.linesep) can be set to LF or CRLF to override the default interpretation of native for checkout. This can be used with hg archive on Unix, say, to generate an archive where files have line endings for Windows.
• eol.only-consistent (default True) can be set to False to make the extension convert files with inconsistent EOLs. Inconsistent means that there is both CRLF and LF present in the file.  Such files are normally not touched under the assumption that they have mixed EOLs on purpose.
• eol.fix-trailing-newline (default False) can be set to True to ensure that converted files end with a EOL character (either \n or \r\n as per the configured patterns).
The extension provides cleverencode: and cleverdecode: filters like the deprecated win32text extension does. This means that you can disable win32text and enable eol and your filters will still work. You only need to these filters until you have prepared a .hgeol file.
The win32text.forbid* hooks provided by the win32text extension have been unified into a single hook named eol.checkheadshook. The hook will lookup the expected line endings from the .hgeol file, which means you must migrate to a .hgeol file first before using the hook. eol.checkheadshook only checks heads, intermediate invalid revisions will be pushed. To forbid them completely, use the eol.checkallhook hook. These hooks are best used as pretxnchangegroup hooks.
See hg help patterns for more information about the glob patterns used.
The extdiff Mercurial extension allows you to use external programs to compare revisions, or revision with working directory. The external diff programs are called with a configurable set of options and two non-option arguments: paths to directories containing snapshots of files to compare.
If there is more than one file being compared and the "child" revision is the working directory, any modifications made in the external diff program will be copied back to the working directory from the temporary directory.
The extdiff extension also allows you to configure new diff commands, so you do not need to type hg extdiff -p kdiff3 always.
[extdiff] # add new command that runs GNU diff(1) in 'context diff' mode cdiff = gdiff -Nprc5 ## or the old way: #cmd.cdiff = gdiff #opts.cdiff = -Nprc5
# add new command called meld, runs meld (no need to name twice).  If # the meld executable is not available, the meld tool in [merge-tools] # will be used, if available meld =
# add new command called vimdiff, runs gvimdiff with DirDiff plugin # (see http://www.vim.org/scripts/script.php?script_id=102) Non # English user, be sure to put "let g:DirDiffDynamicDiffText = 1" in # your .vimrc vimdiff = gvim -f "+next" \ "+execute 'DirDiff' fnameescape(argv(0)) fnameescape(argv(1))"
Tool arguments can include variables that are expanded at runtime:
$parent1, $plabel1 - filename, descriptive label of first parent $child,   $clabel  - filename, descriptive label of child revision $parent2, $plabel2 - filename, descriptive label of second parent $root              - repository root $parent is an alias for $parent1.
The extdiff extension will look in your [diff-tools] and [merge-tools] sections for diff tool arguments, when none are specified in [extdiff].
[extdiff] kdiff3 =
[diff-tools] kdiff3.diffargs=--L1 '$plabel1' --L2 '$clabel' $parent $child
If a program has a graphical interface, it might be interesting to tell Mercurial about it. It will prevent the program from being mistakenly used in a terminal-only environment (such as an SSH terminal session), and will make hg extdiff --per-file open multiple file diffs at once instead of one by one (if you still want to open file diffs one by one, you can use the --confirm option).
Declaring that a tool has a graphical interface can be done with the gui flag next to where diffargs are specified:
[diff-tools] kdiff3.diffargs=--L1 '$plabel1' --L2 '$clabel' $parent $child kdiff3.gui = true
You can use -I/-X and list of file or directory names like normal hg diff command. The extdiff extension makes snapshots of only needed files, so running the external diff program will actually be pretty fast (at least faster than having to compare the entire tree).
Commands File content management extdiff use external program to diff repository (or selected files):
hg extdiff [OPT]... [FILE]...
Show differences between revisions for the specified files, using an external program. The default program used is diff, with default options "-Npru".
To select a different program, use the -p/--program option. The program will be passed the names of two directories to compare, unless the --per-file option is specified (see below). To pass additional options to the program, use -o/--option. These will be passed before the names of the directories or files to compare.
The --from, --to, and --change options work the same way they do for hg diff.
The --per-file option runs the external program repeatedly on each file to diff, instead of once on two directories. By default, this happens one by one, where the next file diff is open in the external program only once the previous external program (for the previous file diff) has exited. If the external program has a graphical interface, it can open all the file diffs at once instead of one by one. See hg help -e extdiff for information about how to tell Mercurial that a given program has a graphical interface.
The --confirm option will prompt the user before each invocation of the external program. It is ignored if --per-file isn't specified.
-p,--program <CMD> comparison program to run
-o,--option <OPT[+]> pass option to comparison program
--per-file compare each file instead of revision snapshots
--confirm prompt user before each external program invocation
--patch compare patches for two revisions
This extension allows the factotum(4) facility on Plan 9 from Bell Labs platforms to provide authentication information for HTTP access. Configuration entries specified in the auth section as well as authentication information provided in the repository URL are fully supported. If no prefix is specified, a value of "*" will be assumed.
By default, keys are specified as:
proto=pass service=hg prefix=<prefix> user=<username> !password=<password>
If the factotum extension is unable to read the required key, one will be requested interactively.
A configuration section is available to customize runtime behavior. By default, these entries are:
[factotum] executable = /bin/auth/factotum mountpoint = /mnt/factotum service = hg
The executable entry defines the full path to the factotum binary. The mountpoint entry defines the path to the factotum file service. Lastly, the service entry controls the service name used when reading keys.
fastannotate yet another annotate implementation that might be faster (EXPERIMENTAL)
The fastannotate extension provides a 'fastannotate' command that makes use of the linelog data structure as a cache layer and is expected to be faster than the vanilla 'annotate' if the cache is present.
In most cases, fastannotate requires a setup that mainbranch is some pointer that always moves forward, to be most efficient.
Using fastannotate together with linkrevcache would speed up building the annotate cache greatly. Run "debugbuildlinkrevcache" before "debugbuildannotatecache".
[fastannotate] # specify the main branch head. the internal linelog will only contain # the linear (ignoring p2) "mainbranch". since linelog cannot move # backwards without a rebuild, this should be something that always moves # forward, usually it is "master" or "@". mainbranch = master
# fastannotate supports different modes to expose its feature. # a list of combination: # - fastannotate: expose the feature via the "fastannotate" command which #   deals with everything in a most efficient way, and provides extra #   features like --deleted etc. # - fctx: replace fctx.annotate implementation. note: #     a. it is less efficient than the "fastannotate" command #     b. it will make it practically impossible to access the old (disk #        side-effect free) annotate implementation #     c. it implies "hgweb". # - hgweb: replace hgweb's annotate implementation. conflict with "fctx". # (default: fastannotate) modes = fastannotate
# default format when no format flags are used (default: number) defaultformat = changeset, user, date
# serve the annotate cache via wire protocol (default: False) # tip: the .hg/fastannotate directory is portable - can be rsynced server = True
# build annotate cache on demand for every client request (default: True) # disabling it could make server response faster, useful when there is a # cronjob building the cache. serverbuildondemand = True
# update local annotate cache from remote on demand client = False
# path to use when connecting to the remote server (default: default) remotepath = default
# minimal length of the history of a file required to fetch linelog from # the server. (default: 10) clientfetchthreshold = 10
# for "fctx" mode, always follow renames regardless of command line option. # this is a BC with the original command but will reduced the space needed # for annotate cache, and is useful for client-server setup since the # server will only provide annotate cache with default options (i.e. with # follow). do not affect "fastannotate" mode. (default: True) forcefollow = True
# for "fctx" mode, always treat file as text files, to skip the "isbinary" # check. this is consistent with the "fastannotate" command and could help # to avoid a file fetch if remotefilelog is used. (default: True) forcetext = True
# use unfiltered repo for better performance. unfilteredrepo = True
# sacrifice correctness in some corner cases for performance. it does not # affect the correctness of the annotate cache being built. the option # is experimental and may disappear in the future (default: False) perfhack = True
Commands Uncategorized commands fastexport export repositories as git fast-import stream
Commands Change import/export fastexport export repository as git fast-import stream:
hg fastexport [OPTION]... [REV]...
This command lets you dump a repository as a human-readable text stream. It can be piped into corresponding import routines like "git fast-import".  Incremental dumps can be created by using marks files.
-i,--import-marks <FILE> old marks file to read
-e,--export-marks <FILE> new marks file to write
fetch pull, update and merge in one command (DEPRECATED)
Commands Remote repository management fetch pull changes from a remote repository, merge new changes if needed.:
hg fetch [SOURCE]
This finds all changes from the repository at the specified path or URL and adds them to the local repository.
If the pulled changes add a new branch head, the head is automatically merged, and the result of the merge is committed.  Otherwise, the working directory is updated to include the new changes.
When a merge is needed, the working directory is first updated to the newly pulled changes. Local changes are then merged into the pulled changes. To switch the merge order, use --switch-parent.
-r,--rev <REV[+]> a specific revision you would like to pull
--edit invoke editor on commit messages
--force-editor edit commit message (DEPRECATED)
--switch-parent switch parents when merging
fix rewrite file content in changesets or working copy (EXPERIMENTAL)
Provides a command that runs configured tools on the contents of modified files, writing back any fixes to the working copy or replacing changesets.
Here is an example configuration that causes hg fix to apply automatic formatting fixes to modified lines in C++ code:
[fix] clang-format:command=clang-format --assume-filename={rootpath} clang-format:linerange=--lines={first}:{last} clang-format:pattern=set:**.cpp or **.hpp
The :command suboption forms the first part of the shell command that will be used to fix a file. The content of the file is passed on standard input, and the fixed file content is expected on standard output. Any output on standard error will be displayed as a warning. If the exit status is not zero, the file will not be affected. A placeholder warning is displayed if there is a non-zero exit status but no standard error output. Some values may be substituted into the command:
{rootpath}  The path of the file being fixed, relative to the repo root {basename}  The name of the file being fixed, without the directory path
If the :linerange suboption is set, the tool will only be run if there are changed lines in a file. The value of this suboption is appended to the shell command once for every range of changed lines in the file. Some values may be substituted into the command:
{first}   The 1-based line number of the first line in the modified range {last}    The 1-based line number of the last line in the modified range
Deleted sections of a file will be ignored by :linerange, because there is no corresponding line range in the version being fixed.
By default, tools that set :linerange will only be executed if there is at least one changed line range. This is meant to prevent accidents like running a code formatter in such a way that it unexpectedly reformats the whole file. If such a tool needs to operate on unchanged files, it should set the :skipclean suboption to false.
The :pattern suboption determines which files will be passed through each configured tool. See hg help patterns for possible values. However, all patterns are relative to the repo root, even if that text says they are relative to the current working directory. If there are file arguments to hg fix, the intersection of these patterns is used.
There is also a configurable limit for the maximum size of file that will be processed by hg fix:
[fix] maxfilesize = 2MB
Normally, execution of configured tools will continue after a failure (indicated by a non-zero exit status). It can also be configured to abort after the first such failure, so that no files will be affected if any tool fails. This abort will also cause hg fix to exit with a non-zero status:
[fix] failure = abort
When multiple tools are configured to affect a file, they execute in an order defined by the :priority suboption. The priority suboption has a default value of zero for each tool. Tools are executed in order of descending priority. The execution order of tools with equal priority is unspecified. For example, you could use the 'sort' and 'head' utilities to keep only the 10 smallest numbers in a text file by ensuring that 'sort' runs before 'head':
[fix] sort:command = sort -n head:command = head -n 10 sort:pattern = numbers.txt head:pattern = numbers.txt sort:priority = 2 head:priority = 1
To account for changes made by each tool, the line numbers used for incremental formatting are recomputed before executing the next tool. So, each tool may see different values for the arguments added by the :linerange suboption.
Each fixer tool is allowed to return some metadata in addition to the fixed file content. The metadata must be placed before the file content on stdout, separated from the file content by a zero byte. The metadata is parsed as a JSON value (so, it should be UTF-8 encoded and contain no zero bytes). A fixer tool is expected to produce this metadata encoding if and only if the :metadata suboption is true:
[fix] tool:command = tool --prepend-json-metadata tool:metadata = true
The metadata values are passed to hooks, which can be used to print summaries or perform other post-fixing work. The supported hooks are:
"postfixfile" Run once for each file in each revision where any fixer tools made changes to the file content. Provides "$HG_REV" and "$HG_PATH" to identify the file, and "$HG_METADATA" with a map of fixer names to metadata values from fixer tools that affected the file. Fixer tools that didn't affect the file have a value of None. Only fixer tools that executed are present in the metadata.
"postfix" Run once after all files and revisions have been handled. Provides "$HG_REPLACEMENTS" with information about what revisions were created and made obsolete. Provides a boolean "$HG_WDIRWRITTEN" to indicate whether any files in the working copy were updated. Provides a list "$HG_METADATA" mapping fixer tool names to lists of metadata values returned from executions that modified a file. This aggregates the same metadata previously passed to the "postfixfile" hook.
Fixer tools are run in the repository's root directory. This allows them to read configuration files from the working copy, or even write to the working copy.  The working copy is not updated to match the revision being fixed. In fact, several revisions may be fixed in parallel. Writes to the working copy are not amended into the revision being fixed; fixer tools should always write fixed file content back to stdout as documented above.
Commands File content management fix rewrite file content in changesets or working directory:
hg fix [OPTION]... [FILE]...
Runs any configured tools to fix the content of files. Only affects files with changes, unless file arguments are provided. Only affects changed lines of files, unless the --whole flag is used. Some tools may always affect the whole file regardless of --whole.
If --working-dir is used, files with uncommitted changes in the working copy will be fixed. Note that no backup are made.
If revisions are specified with --source, those revisions and their descendants will be checked, and they may be replaced with new revisions that have fixed file content. By automatically including the descendants, no merging, rebasing, or evolution will be required. If an ancestor of the working copy is included, then the working copy itself will also be fixed, and the working copy will be updated to the fixed parent.
When determining what lines of each file to fix at each revision, the whole set of revisions being fixed is considered, so that fixes to earlier revisions are not forgotten in later ones. The --base flag can be used to override this default behavior, though it is not usually desirable to do so.
--all  fix all non-public non-obsolete revisions
--base <REV[+]> revisions to diff against (overrides automatic selection, and applies to every revision being fixed)
-r,--rev <REV[+]> revisions to fix (ADVANCED)
-s,--source <REV[+]> fix the specified revisions and their descendants
-w, --working-dir fix the working directory
--whole always fix every line of a file
fsmonitor Faster status operations with the Watchman file monitor (EXPERIMENTAL)
Integrates the file-watching program Watchman with Mercurial to produce faster status results.
On a particular Linux system, for a real-world repository with over 400,000 files hosted on ext4, vanilla hg status takes 1.3 seconds. On the same system, with fsmonitor it takes about 0.3 seconds.
fsmonitor requires no configuration -- it will tell Watchman about your repository as necessary. You'll need to install Watchman from https://facebook.github.io/watchman/ and make sure it is in your PATH.
fsmonitor is incompatible with the largefiles and eol extensions, and will disable itself if any of those are active.
The following configuration options exist:
[fsmonitor] mode = {off, on, paranoid}
When mode = off, fsmonitor will disable itself (similar to not loading the extension at all). When mode = on, fsmonitor will be enabled (the default).  When mode = paranoid, fsmonitor will query both Watchman and the filesystem, and ensure that the results are consistent.
[fsmonitor] timeout = (float)
A value, in seconds, that determines how long fsmonitor will wait for Watchman to return results. Defaults to 2.0.
[fsmonitor] blacklistusers = (list of userids)
A list of usernames for which fsmonitor will disable itself altogether.
[fsmonitor] walk_on_invalidate = (boolean)
Whether or not to walk the whole repo ourselves when our cached state has been invalidated, for example when Watchman has been restarted or .hgignore rules have been changed. Walking the repo in that case can result in competing for I/O with Watchman. For large repos it is recommended to set this value to false. You may wish to set this to true if you have a very fast filesystem that can outpace the IPC overhead of getting the result data for the full repo from Watchman. Defaults to false.
[fsmonitor] warn_when_unused = (boolean)
Whether to print a warning during certain operations when fsmonitor would be beneficial to performance but isn't enabled.
[fsmonitor] warn_update_file_count = (integer) # or when mercurial is built with rust support warn_update_file_count_rust = (integer)
If warn_when_unused is set and fsmonitor isn't enabled, a warning will be printed during working directory updates if this many files will be created.
git grant Mercurial the ability to operate on Git repositories. (EXPERIMENTAL)
This is currently super experimental. It probably will consume your firstborn a la Rumpelstiltskin, etc.
Tries to map a given git command to a Mercurial command:
$ hg githelp -- git checkout master hg update master
If an unknown command or parameter combination is detected, an error is produced.
Commands Help githelp suggests the Mercurial equivalent of the given git command:
hg githelp
Usage: hg githelp -- <git command>
aliases: git
gpg commands to sign and verify changesets
Commands Signing changes (GPG) sigcheck verify all the signatures there may be for a particular revision:
hg sigcheck REV
verify all the signatures there may be for a particular revision
sign add a signature for the current or given revision:
hg sign [OPTION]... [REV]...
If no revision is given, the parent of the working directory is used, or tip if no revision is checked out.
The gpg.cmd config setting can be used to specify the command to run. A default key can be specified with gpg.key.
-l, --local make the signature local
-f, --force sign even if the sigfile is modified
--no-commit do not commit the sigfile after signing
-k,--key <ID> the key id to sign with
sigs list signed changesets:
hg sigs
list signed changesets
graphlog command to view revision graphs from a shell (DEPRECATED)
The functionality of this extension has been include in core Mercurial since version 2.3. Please use hg log -G ... instead.
This extension adds a --graph option to the incoming, outgoing and log commands. When this options is given, an ASCII representation of the revision graph is also shown.
Commands Change navigation glog show revision history alongside an ASCII revision graph:
hg glog [OPTION]... [FILE]
Print a revision history alongside a revision graph drawn with ASCII characters.
Nodes printed as an @ character are parents of the working directory.
This is an alias to hg log -G.
-r,--rev <REV[+]> show the specified revision or revset
-m, --only-merges show only merges (DEPRECATED)
hgk browse the repository in a graphical way
The hgk extension allows browsing the history of a repository in a graphical way. It requires Tcl/Tk version 8.4 or later. (Tcl/Tk is not distributed with Mercurial.)
hgk consists of two parts: a Tcl script that does the displaying and querying of information, and an extension to Mercurial named hgk.py, which provides hooks for hgk to get information. hgk can be found in the contrib directory, and the extension is shipped in the hgext repository, and needs to be enabled.
The hg view command will launch the hgk Tcl script. For this command to work, hgk must be in your search path. Alternately, you can specify the path to hgk in your configuration file:
[hgk] path = /location/of/hgk
hgk can make use of the extdiff extension to visualize revisions. Assuming you had already configured extdiff vdiff command, just add:
[hgk] vdiff=vdiff
Revisions context menu will now display additional entries to fire vdiff on hovered and selected revisions.
Commands Change navigation view start interactive history viewer:
hg view [-l LIMIT] [REVRANGE]
start interactive history viewer
Uncategorized commands highlight syntax highlighting for hgweb (requires Pygments)
It depends on the Pygments syntax highlighting library: http://pygments.org/
There are the following configuration options:
[web] pygments_style = <style> (default: colorful) highlightfiles = <fileset> (default: size('<5M')) highlightonlymatchfilename = <bool> (default False)
highlightonlymatchfilename will only highlight files if their type could be identified by their filename. When this is not enabled (the default), Pygments will try very hard to identify the file type from content and any match (even matches with a low confidence score) will be used.
With this extension installed, Mercurial gains one new command: histedit. Usage is as follows, assuming the following history:
@  3[tip]   7c2fd3b9020c   2009-04-27 18:04 -0500   durin42 |    Add delta | o  2   030b686bedc4   2009-04-27 18:04 -0500   durin42 |    Add gamma | o  1   c561b4e977df   2009-04-27 18:04 -0500   durin42 |    Add beta | o  0   d8d2fcd0e319   2009-04-27 18:04 -0500   durin42 Add alpha
If you were to run hg histedit c561b4e977df, you would see the following file open in your editor:
pick c561b4e977df Add beta pick 030b686bedc4 Add gamma pick 7c2fd3b9020c Add delta
# Edit history between c561b4e977df and 7c2fd3b9020c # # Commits are listed from least to most recent # # Commands: #  p, pick = use commit #  e, edit = use commit, but allow edits before making new commit #  f, fold = use commit, but combine it with the one above #  r, roll = like fold, but discard this commit's description and date #  d, drop = remove commit from history #  m, mess = edit commit message without changing commit content #  b, base = checkout changeset and apply further changesets from there #
In this file, lines beginning with # are ignored. You must specify a rule for each revision in your history. For example, if you had meant to add gamma before beta, and then wanted to add delta in the same revision as beta, you would reorganize the file to look like this:
pick 030b686bedc4 Add gamma pick c561b4e977df Add beta fold 7c2fd3b9020c Add delta
At which point you close the editor and histedit starts working. When you specify a fold operation, histedit will open an editor when it folds those revisions together, offering you a chance to clean up the commit message:
Add beta *** Add delta
Edit the commit message to your liking, then close the editor. The date used for the commit will be the later of the two commits' dates. For this example, let's assume that the commit message was changed to Add beta and delta.  After histedit has run and had a chance to remove any old or temporary revisions it needed, the history looks like this:
@  2[tip]   989b4d060121   2009-04-27 18:04 -0500   durin42 |    Add beta and delta. | o  1   081603921c3f   2009-04-27 18:04 -0500   durin42 |    Add gamma | o  0   d8d2fcd0e319   2009-04-27 18:04 -0500   durin42 Add alpha
Note that histedit does not remove any revisions (even its own temporary ones) until after it has completed all the editing operations, so it will probably perform several strip operations when it's done. For the above example, it had to run strip twice. Strip can be slow depending on a variety of factors, so you might need to be a little patient. You can choose to keep the original revisions by passing the --keep flag.
The edit operation will drop you back to a command prompt, allowing you to edit files freely, or even use hg record to commit some changes as a separate commit. When you're done, any remaining uncommitted changes will be committed as well. When done, run hg histedit --continue to finish this step. If there are uncommitted changes, you'll be prompted for a new commit message, but the default commit message will be the original message for the edit ed revision, and the date of the original commit will be preserved.
The message operation will give you a chance to revise a commit message without changing the contents. It's a shortcut for doing edit immediately followed by hg histedit --continue`.
If histedit encounters a conflict when moving a revision (while handling pick or fold), it'll stop in a similar manner to edit with the difference that it won't prompt you for a commit message when done. If you decide at this point that you don't like how much work it will be to rearrange history, or that you made a mistake, you can use hg histedit --abort to abandon the new changes you have made and return to the state before you attempted to edit your history.
If we clone the histedit-ed example repository above and add four more changes, such that we have the following history:
@  6[tip]   038383181893   2009-04-27 18:04 -0500   stefan |    Add theta | o  5   140988835471   2009-04-27 18:04 -0500   stefan |    Add eta | o  4   122930637314   2009-04-27 18:04 -0500   stefan |    Add zeta | o  3   836302820282   2009-04-27 18:04 -0500   stefan |    Add epsilon | o  2   989b4d060121   2009-04-27 18:04 -0500   durin42 |    Add beta and delta. | o  1   081603921c3f   2009-04-27 18:04 -0500   durin42 |    Add gamma | o  0   d8d2fcd0e319   2009-04-27 18:04 -0500   durin42 Add alpha
If you run hg histedit --outgoing on the clone then it is the same as running hg histedit 836302820282. If you need plan to push to a repository that Mercurial does not detect to be related to the source repo, you can add a --force option.
Config Histedit rule lines are truncated to 80 characters by default. You can customize this behavior by setting a different length in your configuration file:
[histedit] linelen = 120      # truncate rule lines at 120 characters
The summary of a change can be customized as well:
[histedit] summary-template = '{rev} {bookmarks} {desc|firstline}'
The customized summary should be kept short enough that rule lines will fit in the configured line length. See above if that requires customization.
hg histedit attempts to automatically choose an appropriate base revision to use. To change which base revision is used, define a revset in your configuration file:
[histedit] defaultrev = only(.) & draft()
By default each edited revision needs to be present in histedit commands. To remove revision you need to use drop operation. You can configure the drop to be implicit for missing commits by adding:
[histedit] dropmissing = True
By default, histedit will close the transaction after each action. For performance purposes, you can configure histedit to use a single transaction across the entire histedit. WARNING: This setting introduces a significant risk of losing the work you've done in a histedit if the histedit aborts unexpectedly:
[histedit] singletransaction = True
Commands Change manipulation histedit interactively edit changeset history:
hg histedit [OPTIONS] ([ANCESTOR] | --outgoing [URL])
This command lets you edit a linear series of changesets (up to and including the working directory, which should be clean).  You can:
• pick to [re]order a changeset
• drop to omit changeset
• mess to reword the changeset commit message
• fold to combine it with the preceding changeset (using the later date)
• roll like fold, but discarding this commit's description and date
• edit to edit this changeset (preserving date)
• base to checkout changeset and apply further changesets from there
There are a number of ways to select the root changeset:
• Specify ANCESTOR directly
• Use --outgoing -- it will be the first linear changeset not included in destination. (See hg help config.paths.default-push)
• Otherwise, the value from the "histedit.defaultrev" config option is used as a revset to select the base revision when ANCESTOR is not specified. The first revision returned by the revset is used. By default, this selects the editable history that is unique to the ancestry of the working directory.
If you use --outgoing, this command will abort if there are ambiguous outgoing revisions. For example, if there are multiple branches containing outgoing revisions.
Use "min(outgoing() and ::.)" or similar revset specification instead of --outgoing to specify edit target revision exactly in such ambiguous situation. See hg help revsets for detail about selecting revisions.
• A number of changes have been made.  Revision 3 is no longer needed.
Start history editing from revision 3:
hg histedit -r 3
An editor opens, containing the list of revisions, with specific actions specified:
pick 5339bf82f0ca 3 Zworgle the foobar pick 8ef592ce7cc4 4 Bedazzle the zerlog pick 0a9639fcda9d 5 Morgify the cromulancy
Additional information about the possible actions to take appears below the list of revisions.
To remove revision 3 from the history, its action (at the beginning of the relevant line) is changed to 'drop':
drop 5339bf82f0ca 3 Zworgle the foobar pick 8ef592ce7cc4 4 Bedazzle the zerlog pick 0a9639fcda9d 5 Morgify the cromulancy
• A number of changes have been made.  Revision 2 and 4 need to be swapped.
Start history editing from revision 2:
hg histedit -r 2
pick 252a1af424ad 2 Blorb a morgwazzle pick 5339bf82f0ca 3 Zworgle the foobar pick 8ef592ce7cc4 4 Bedazzle the zerlog
To swap revision 2 and 4, its lines are swapped in the editor:
pick 8ef592ce7cc4 4 Bedazzle the zerlog pick 5339bf82f0ca 3 Zworgle the foobar pick 252a1af424ad 2 Blorb a morgwazzle
Returns 0 on success, 1 if user intervention is required (not only for intentional "edit" command, but also for resolving unexpected conflicts).
--commands <FILE> read history edits from the specified file
-c, --continue continue an edit already in progress
--edit-plan edit remaining actions list
-k, --keep don't strip old nodes after edit is complete
--abort abort an edit in progress
-o, --outgoing changesets not found in destination
-f, --force force outgoing even for unrelated repositories
-r,--rev <REV[+]> first revision to be edited
hooklib collection of simple hooks for common tasks (EXPERIMENTAL)
This extension provides a number of simple hooks to handle issues commonly found in repositories with many contributors: - email notification when changesets move from draft to public phase - email notification when changesets are obsoleted - enforcement of draft phase for all incoming changesets - enforcement of a no-branch-merge policy - enforcement of a no-multiple-heads policy
The implementation of the hooks is subject to change, e.g. whether to implement them as individual hooks or merge them into the notify extension as option. The functionality itself is planned to be supported long-term.
infinitepush store some pushes in a remote blob store on the server (EXPERIMENTAL)
IMPORTANT: if you use this extension, please contact mercurial-devel@mercurial-scm.org ASAP. This extension is believed to be unused and barring learning of users of this functionality, we will delete this code at the end of 2020.
[infinitepush] # Server-side and client-side option. Pattern of the infinitepush bookmark branchpattern = PATTERN
# Server or client server = False
# Server-side option. Possible values: 'disk' or 'sql'. Fails if not set indextype = disk
# Server-side option. Used only if indextype=sql.  # Format: 'IP:PORT:DB_NAME:USER:PASSWORD' sqlhost = IP:PORT:DB_NAME:USER:PASSWORD
# Server-side option. Used only if indextype=disk.  # Filesystem path to the index store indexpath = PATH
# Server-side option. Possible values: 'disk' or 'external' # Fails if not set storetype = disk
# Server-side option.  # Path to the binary that will save bundle to the bundlestore # Formatted cmd line will be passed to it (see put_args) put_binary = put
# Serser-side option. Used only if storetype=external.  # Format cmd-line string for put binary. Placeholder: {filename} put_args = {filename}
# Server-side option.  # Path to the binary that get bundle from the bundlestore.  # Formatted cmd line will be passed to it (see get_args) get_binary = get
# Serser-side option. Used only if storetype=external.  # Format cmd-line string for get binary. Placeholders: {filename} {handle} get_args = {filename} {handle}
# Server-side option logfile = FIlE
# Server-side option loglevel = DEBUG
# Server-side option. Used only if indextype=sql.  # Sets mysql wait_timeout option.  waittimeout = 300
# Server-side option. Used only if indextype=sql.  # Sets mysql innodb_lock_wait_timeout option.  locktimeout = 120
# Server-side option. Used only if indextype=sql.  # Name of the repository reponame = ''
# Client-side option. Used by --list-remote option. List of remote scratch # patterns to list if no patterns are specified. defaultremotepatterns = ['*']
# Instructs infinitepush to forward all received bundle2 parts to the # bundle for storage. Defaults to False.  storeallparts = True
# routes each incoming push to the bundlestore. defaults to False pushtobundlestore = True
[remotenames] # Client-side option # This option should be set only if remotenames extension is enabled.  # Whether remote bookmarks are tracked by remotenames extension.  bookmarks = True
journal track previous positions of bookmarks (EXPERIMENTAL)
This extension adds a new command: hg journal, which shows you where bookmarks were previously located.
Commands Change organization journal show the previous position of bookmarks and the working copy:
hg journal [OPTION]... [BOOKMARKNAME]
The journal is used to see the previous commits that bookmarks and the working copy pointed to. By default the previous locations for the working copy.  Passing a bookmark name will show all the previous positions of that bookmark. Use the --all switch to show previous locations for all bookmarks and the working copy; each line will then include the bookmark name, or '.' for the working copy, as well.
If name starts with re:, the remainder of the name is treated as a regular expression. To match a name that actually starts with re:, use the prefix literal:.
By default hg journal only shows the commit hash and the command that was running at that time. -v/--verbose will show the prior hash, the user, and the time at which it happened.
Use -c/--commits to output log information on each commit hash; at this point you can use the usual --patch, --git, --stat and --template switches to alter the log output for these.
hg journal -T json can be used to produce machine readable output.
--all  show history for all names
-c, --commits show commit metadata
This extension expands RCS/CVS-like or self-customized $Keywords$ in tracked text files selected by your configuration.
Keywords are only expanded in local repositories and not stored in the change history. The mechanism can be regarded as a convenience for the current user or for archive distribution.
Keywords expand to the changeset data pertaining to the latest change relative to the working directory parent of each file.
Configuration is done in the [keyword], [keywordset] and [keywordmaps] sections of hgrc files.
[keyword] # expand keywords in every python file except those matching "x*" **.py = x*    = ignore
[keywordset] # prefer svn- over cvs-like default keywordmaps svn = True
Note   The more specific you are in your filename patterns the less you lose speed in huge repositories.
For [keywordmaps] template mapping and expansion demonstration and control run hg kwdemo. See hg help templates for a list of available templates and filters.
Three additional date template filters are provided:
utcdate
"2006/09/18 15:13:13"
svnutcdate
"2006-09-18 15:13:13Z"
svnisodate
"2006-09-18 08:13:13 -700 (Mon, 18 Sep 2006)"
The default template mappings (view with hg kwdemo -d) can be replaced with customized keywords and templates. Again, run hg kwdemo to control the results of your configuration changes.
Before changing/disabling active keywords, you must run hg kwshrink to avoid storing expanded keywords in the change history.
To force expansion after enabling it, or a configuration change, run hg kwexpand.
Expansions spanning more than one line and incremental expansions, like CVS' $Log$, are not supported. A keyword template map "Log = {desc}" expands to the first line of the changeset description.
Commands Uncategorized commands kwdemo print [keywordmaps] configuration and an expansion example:
hg kwdemo [-d] [-f RCFILE] [TEMPLATEMAP]...
Show current, custom, or default keyword template maps and their expansions.
Extend the current configuration by specifying maps as arguments and using -f/--rcfile to source an external hgrc file.
Use -d/--default to disable current configuration.