Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
HG(1)			       Mercurial Manual				 HG(1)

NAME
       hg - Mercurial source code management system

SYNOPSIS
       hg command [option]... [argument]...

DESCRIPTION
       The  hg command provides	a command line interface to the	Mercurial sys-
       tem.

COMMAND	ELEMENTS
       files...
	      indicates	one or more filename or	relative path  filenames;  see
	      File Name	Patterns for information on pattern matching

       path   indicates	a path on the local machine

       revision
	      indicates	 a changeset which can be specified as a changeset re-
	      vision number, a tag, or a unique	 substring  of	the  changeset
	      hash value

       repository path
	      either the pathname of a local repository	or the URI of a	remote
	      repository.

OPTIONS
       -R,--repository <REPO>
	      repository root directory	or name	of overlay bundle file

       --cwd _DIR_
	      change working directory

       -y, --noninteractive
	      do not prompt, automatically  pick  the  first  choice  for  all
	      prompts

       -q, --quiet
	      suppress output

       -v, --verbose
	      enable additional	output

       --color _TYPE_
	      when to colorize (boolean, always, auto, never, or debug)

       --config	_CONFIG[+]_
	      set/override config option (use 'section.name=value')

       --debug
	      enable debugging output

       --debugger
	      start debugger

       --encoding _ENCODE_
	      set the charset encoding (default: UTF-8)

       --encodingmode _MODE_
	      set the charset encoding mode (default: strict)

       --traceback
	      always print a traceback on exception

       --time time how long the	command	takes

       --profile
	      print command execution profile

       --version
	      output version information and exit

       -h, --help
	      display help and exit

       --hidden
	      consider hidden changesets

       --pager _TYPE_
	      when  to	paginate  (boolean,  always, auto, or never) (default:
	      auto)

       [+] marked option can be	specified multiple times

COMMANDS
   Repository creation
   clone
       make a copy of an existing repository:

       hg clone	[OPTION]... SOURCE [DEST]

       Create a	copy of	an existing repository in a new	directory.

       If no destination directory name	is specified, it defaults to the base-
       name of the source.

       The  location  of  the source is	added to the new repository's .hg/hgrc
       file, as	the default to be used for future pulls.

       Only local paths	and ssh:// URLs	are  supported	as  destinations.  For
       ssh://  destinations,  no working directory or .hg/hgrc will be created
       on the remote side.

       If the source repository	has a bookmark called '@' set,	that  revision
       will be checked out in the new repository by default.

       To check	out a particular version, use -u/--update, or -U/--noupdate to
       create a	clone with no working directory.

       To pull only a subset of	changesets,  specify  one  or  more  revisions
       identifiers  with  -r/--rev or branches with -b/--branch. The resulting
       clone will contain only the specified changesets	and  their  ancestors.
       These  options  (or  'clone src#rev dest') imply	--pull,	even for local
       source repositories.

       In normal clone mode, the remote	normalizes repository data into	a com-
       mon exchange format and the receiving end translates this data into its
       local storage format. --stream activates	a different  clone  mode  that
       essentially  copies  repository files from the remote with minimal data
       processing. This	significantly reduces the CPU cost of a	clone both re-
       motely  and  locally.  However, it often	increases the transferred data
       size by 30-40%. This can	result in substantially	 faster	 clones	 where
       I/O  throughput	is  plentiful,	especially  for	larger repositories. A
       side-effect of --stream clones is that storage  settings	 and  require-
       ments  on  the  remote are applied locally: a modern client may inherit
       legacy or inefficient storage used by the remote	or a legacy  Mercurial
       client may not be able to clone from a modern Mercurial remote.

       Note   Specifying  a  tag will include the tagged changeset but not the
	      changeset	containing the tag.

       For efficiency, hardlinks are used for cloning whenever the source  and
       destination  are	 on the	same filesystem	(note this applies only	to the
       repository data,	not to the working directory). Some filesystems,  such
       as AFS, implement hardlinking incorrectly, but do not report errors. In
       these cases, use	the --pull option to avoid hardlinking.

       Mercurial will update the working directory to the first	applicable re-
       vision from this	list:

       a. null if -U or	the source repository has no changesets

       b. if  -u . and the source repository is	local, the first parent	of the
	  source repository's working directory

       c. the changeset	specified with -u (if a	branch name,  this  means  the
	  latest head of that branch)

       d. the changeset	specified with -r

       e. the tipmost head specified with -b

       f. the tipmost head specified with the url#branch source	syntax

       g. the revision marked with the '@' bookmark, if	present

       h. the tipmost head of the default branch

       i. tip

       When cloning from servers that support it, Mercurial may	fetch pre-gen-
       erated data from	a  server-advertised  URL  or  inline  from  the  same
       stream.	When  this is done, hooks operating on incoming	changesets and
       changegroups may	fire more than once, once for each pre-generated  bun-
       dle  and	 as well as for	any additional remaining data. In addition, if
       an error	occurs,	the repository may be rolled back to a partial	clone.
       This  behavior  may  change in future releases.	See hg help -e cloneb-
       undles for more.

       Examples:

       o clone a remote	repository to a	new directory named hg/:

	 hg clone https://www.mercurial-scm.org/repo/hg/

       o create	a lightweight local clone:

	 hg clone project/ project-feature/

       o clone from an absolute	path on	an ssh server (note double-slash):

	 hg clone ssh://user@server//home/projects/alpha/

       o do a streaming	clone while checking out a specified version:

	 hg clone --stream http://server/repo -u 1.5

       o create	a repository without changesets	after a	particular revision:

	 hg clone -r 04e544 experimental/ good/

       o clone (and track) a particular	named branch:

	 hg clone https://www.mercurial-scm.org/repo/hg/#stable

       See hg help urls	for details on specifying URLs.

       Returns 0 on success.

       Options:

       -U, --noupdate
	      the clone	will include an	empty working directory	(only a	repos-
	      itory)

       -u,--updaterev <REV>
	      revision,	tag, or	branch to check	out

       -r,--rev	<REV[+]>
	      do  not clone everything,	but include this changeset and its an-
	      cestors

       -b,--branch <BRANCH[+]>
	      do not clone everything, but include  this  branch's  changesets
	      and their	ancestors

       --pull use pull protocol	to copy	metadata

       --uncompressed
	      an alias to --stream (DEPRECATED)

       --stream
	      clone with minimal data processing

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   init
       create a	new repository in the given directory:

       hg init [-e CMD]	[--remotecmd CMD] [DEST]

       Initialize a new	repository in the given	directory. If the given	direc-
       tory does not exist, it will be created.

       If no directory is given, the current directory is used.

       It is possible to specify an ssh:// URL as  the	destination.   See  hg
       help urls for more information.

       Returns 0 on success.

       Options:

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

   Remote repository management
   incoming
       show new	changesets found in source:

       hg incoming [-p]	[-n] [-M] [-f] [-r REV]... [--bundle FILENAME] [SOURCE]

       Show new	changesets found in the	specified path/URL or the default pull
       location. These are the changesets that would have been	pulled	by  hg
       pull at the time	you issued this	command.

       See pull	for valid source format	details.

       With  -B/--bookmarks,  the  result of bookmark comparison between local
       and remote repositories is displayed. With -v/--verbose,	status is also
       displayed for each bookmark like	below:

       BM1		 01234567890a added
       BM2		 1234567890ab advanced
       BM3		 234567890abc diverged
       BM4		 34567890abcd changed

       The  action  taken  locally  when pulling depends on the	status of each
       bookmark:

       added

	      pull will	create it

       advanced

	      pull will	update it

       diverged

	      pull will	create a divergent bookmark

       changed

	      result depends on	remote changesets

       From the	point of view of pulling behavior, bookmark existing  only  in
       the  remote  repository are treated as added, even if it	is in fact lo-
       cally deleted.

       For remote repository, using --bundle avoids downloading	the changesets
       twice if	the incoming is	followed by a pull.

       Examples:

       o show incoming changes with patches and	full description:

	 hg incoming -vp

       o show incoming changes excluding merges, store a bundle:

	 hg in -vpM --bundle incoming.hg
	 hg pull incoming.hg

       o briefly list changes inside a bundle:

	 hg in changes.hg -T "{desc|firstline}\n"

       Returns 0 if there are incoming changes,	1 otherwise.

       Options:

       -f, --force
	      run even if remote repository is unrelated

       -n, --newest-first
	      show newest record first

       --bundle	_FILE_
	      file to store the	bundles	into

       -r,--rev	<REV[+]>
	      a	remote changeset intended to be	added

       -B, --bookmarks
	      compare bookmarks

       -b,--branch <BRANCH[+]>
	      a	specific branch	you would like to pull

       -p, --patch
	      show patch

       -g, --git
	      use git extended diff format

       -l,--limit <NUM>
	      limit number of changes displayed

       -M, --no-merges
	      do not show merges

       --stat output diffstat-style summary of changes

       -G, --graph
	      show the revision	DAG

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

	  aliases: in

   outgoing
       show changesets not found in the	destination:

       hg outgoing [-M]	[-p] [-n] [-f] [-r REV]... [DEST]

       Show  changesets	 not  found in the specified destination repository or
       the default push	location. These	 are  the  changesets  that  would  be
       pushed if a push	was requested.

       See pull	for details of valid destination formats.

       With  -B/--bookmarks,  the  result of bookmark comparison between local
       and remote repositories is displayed. With -v/--verbose,	status is also
       displayed for each bookmark like	below:

       BM1		 01234567890a added
       BM2			      deleted
       BM3		 234567890abc advanced
       BM4		 34567890abcd diverged
       BM5		 4567890abcde changed

       The action taken	when pushing depends on	the status of each bookmark:

       added

	      push with	-B will	create it

       deleted

	      push with	-B will	delete it

       advanced

	      push will	update it

       diverged

	      push with	-B will	update it

       changed

	      push with	-B will	update it

       From  the point of view of pushing behavior, bookmarks existing only in
       the remote repository are treated as deleted, even if  it  is  in  fact
       added remotely.

       Returns 0 if there are outgoing changes,	1 otherwise.

       Options:

       -f, --force
	      run even when the	destination is unrelated

       -r,--rev	<REV[+]>
	      a	changeset intended to be included in the destination

       -n, --newest-first
	      show newest record first

       -B, --bookmarks
	      compare bookmarks

       -b,--branch <BRANCH[+]>
	      a	specific branch	you would like to push

       -p, --patch
	      show patch

       -g, --git
	      use git extended diff format

       -l,--limit <NUM>
	      limit number of changes displayed

       -M, --no-merges
	      do not show merges

       --stat output diffstat-style summary of changes

       -G, --graph
	      show the revision	DAG

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

	  aliases: out

   paths
       show aliases for	remote repositories:

       hg paths	[NAME]

       Show  definition	 of symbolic path name NAME. If	no name	is given, show
       definition of all available names.

       Option -q/--quiet suppresses all	output when  searching	for  NAME  and
       shows only the path names when listing all definitions.

       Path  names  are	 defined  in the [paths] section of your configuration
       file and	in /etc/mercurial/hgrc.	If run inside a	 repository,  .hg/hgrc
       is used,	too.

       The  path  names	default	and default-push have a	special	meaning.  When
       performing a push or pull operation, they are used as fallbacks	if  no
       location	 is  specified on the command-line.  When default-push is set,
       it will be used for push	and default will be used for  pull;  otherwise
       default	is  used as the	fallback for both.  When cloning a repository,
       the clone source	is written as default in .hg/hgrc.

       Note   default and default-push apply to	all inbound (e.g.  hg incoming
	      )	and outbound (e.g. hg outgoing,	hg email and hg	bundle)	opera-
	      tions.

       See hg help urls	for more information.

       Template:

       The following keywords are supported. See also hg help templates.

       name   String. Symbolic name of the path	alias.

       pushurl
	      String. URL for push operations.

       url    String. URL or directory path for	the other operations.

       Returns 0 on success.

       Options:

       -T,--template <TEMPLATE>
	      display with template

   pull
       pull changes from the specified source:

       hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD]	[SOURCE]

       Pull changes from a remote repository to	a local	one.

       This finds all changes from the repository at the specified path	or URL
       and adds	them to	a local	repository (the	current	one unless -R is spec-
       ified). By default, this	does not update	the copy of the	project	in the
       working directory.

       When cloning from servers that support it, Mercurial may	fetch pre-gen-
       erated data. When this is done, hooks operating on incoming  changesets
       and  changegroups  may fire more	than once, once	for each pre-generated
       bundle and as well as for any additional	remaining data.	See hg help -e
       clonebundles for	more.

       Use hg incoming if you want to see what would have been added by	a pull
       at the time you issued this command. If you then	decide	to  add	 those
       changes	to  the	repository, you	should use hg pull -r X	where X	is the
       last changeset listed by	hg incoming.

       If SOURCE is omitted, the 'default' path	will be	 used.	 See  hg  help
       urls for	more information.

       Specifying  bookmark  as	. is equivalent	to specifying the active book-
       mark's name.

       Returns 0 on success, 1 if an update had	unresolved files.

       Options:

       -u, --update
	      update to	new branch head	if new descendants were	pulled

       -f, --force
	      run even when remote repository is unrelated

       -r,--rev	<REV[+]>
	      a	remote changeset intended to be	added

       -B,--bookmark <BOOKMARK[+]>
	      bookmark to pull

       -b,--branch <BRANCH[+]>
	      a	specific branch	you would like to pull

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   push
       push changes to the specified destination:

       hg push [-f] [-r	REV]...	[-e CMD] [--remotecmd CMD] [DEST]

       Push changesets from the	local repository to the	specified destination.

       This operation is symmetrical to	pull: it is identical to a pull	in the
       destination repository from the current one.

       By  default,  push will not allow creation of new heads at the destina-
       tion, since multiple heads would	make it	unclear	which head to use.  In
       this situation, it is recommended to pull and merge before pushing.

       Use --new-branch	if you want to allow push to create a new named	branch
       that is not present at the destination. This allows you to only	create
       a new branch without forcing other changes.

       Note   Extra  care  should  be  taken with the -f/--force option, which
	      will push	all new	heads on all branches, an  action  which  will
	      almost always cause confusion for	collaborators.

       If  -r/--rev is used, the specified revision and	all its	ancestors will
       be pushed to the	remote repository.

       If -B/--bookmark	is used, the specified bookmarked revision, its	ances-
       tors,  and the bookmark will be pushed to the remote repository.	Speci-
       fying . is equivalent to	specifying the active bookmark's name.

       Please see hg help urls for important details  about  ssh://  URLs.  If
       DESTINATION is omitted, a default path will be used.

       The  --pushvars option sends strings to the server that become environ-
       ment variables prepended	with HG_USERVAR_. For example, --pushvars  EN-
       ABLE_FEATURE=true,  provides  the server	side hooks with	HG_USERVAR_EN-
       ABLE_FEATURE=true as part of their environment.

       pushvars	can provide for	user-overridable hooks as well	as  set	 debug
       levels.	One  example  is  having a hook	that blocks commits containing
       conflict	markers, but enables the user to override the hook if the file
       is  using  conflict markers for testing purposes	or the file format has
       strings that look like conflict markers.

       By default, servers will	ignore --pushvars. To enable it	add  the  fol-
       lowing to your configuration file:

       [push]
       pushvars.server = true

       Returns 0 if push was successful, 1 if nothing to push.

       Options:

       -f, --force
	      force push

       -r,--rev	<REV[+]>
	      a	changeset intended to be included in the destination

       -B,--bookmark <BOOKMARK[+]>
	      bookmark to push

       -b,--branch <BRANCH[+]>
	      a	specific branch	you would like to push

       --new-branch
	      allow pushing a new branch

       --pushvars _VALUE[+]_
	      variables	that can be sent to server (ADVANCED)

       --publish
	      push the changeset as public (EXPERIMENTAL)

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   serve
       start stand-alone webserver:

       hg serve	[OPTION]...

       Start a local HTTP repository browser and pull server. You can use this
       for ad-hoc sharing and browsing of repositories.	It is  recommended  to
       use a real web server to	serve a	repository for longer periods of time.

       Please  note  that  the server does not implement access	control.  This
       means that, by default, anybody can read	from the server	and nobody can
       write to	it by default. Set the web.allow-push option to	* to allow ev-
       erybody to push to the server. You should use a real web	server if  you
       need to authenticate users.

       By  default,  the  server logs accesses to stdout and errors to stderr.
       Use the -A/--accesslog and -E/--errorlog	options	to log to files.

       To have the server choose a free	port number to listen  on,  specify  a
       port  number  of	0; in this case, the server will print the port	number
       it uses.

       Returns 0 on success.

       Options:

       -A,--accesslog <FILE>
	      name of access log file to write to

       -d, --daemon
	      run server in background

       --daemon-postexec _VALUE[+]_
	      used internally by daemon	mode

       -E,--errorlog <FILE>
	      name of error log	file to	write to

       -p,--port <PORT>
	      port to listen on	(default: 8000)

       -a,--address <ADDR>
	      address to listen	on (default: all interfaces)

       --prefix	_PREFIX_
	      prefix path to serve from	(default: server root)

       -n,--name <NAME>
	      name to show in web pages	(default: working directory)

       --web-conf _FILE_
	      name of the hgweb	config file (see 'hg help hgweb')

       --webdir-conf _FILE_
	      name of the hgweb	config file (DEPRECATED)

       --pid-file _FILE_
	      name of file to write process ID to

       --stdio
	      for remote clients (ADVANCED)

       --cmdserver _MODE_
	      for remote clients (ADVANCED)

       -t,--templates <TEMPLATE>
	      web templates to use

       --style _STYLE_
	      template style to	use

       -6, --ipv6
	      use IPv6 in addition to IPv4

       --certificate _FILE_
	      SSL certificate file

       --print-url
	      start and	print only the URL

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

   Change creation
   commit
       commit the specified files or all outstanding changes:

       hg commit [OPTION]... [FILE]...

       Commit changes to the given files into the repository.  Unlike  a  cen-
       tralized	 SCM,  this  operation is a local operation. See hg push for a
       way to actively distribute your changes.

       If a list of files is omitted, all changes reported by  hg  status will
       be committed.

       If  you	are committing the result of a merge, do not provide any file-
       names or	-I/-X filters.

       If no commit message is specified, Mercurial starts your	configured ed-
       itor where you can enter	a message. In case your	commit fails, you will
       find a backup of	your message in	.hg/last-message.txt.

       The --close-branch flag can be used to mark  the	 current  branch  head
       closed.	When all heads of a branch are closed, the branch will be con-
       sidered closed and no longer listed.

       The --amend flag	can be used to amend the parent	of the working	direc-
       tory with a new commit that contains the	changes	in the parent in addi-
       tion to those currently reported	by hg status, if there	are  any.  The
       old  commit  is	stored	in a backup bundle in .hg/strip-backup (see hg
       help bundle and hg help unbundle	on how to restore it).

       Message,	user and date are taken	from the amended commit	unless	speci-
       fied.  When  a  message isn't specified on the command line, the	editor
       will open with the message of the amended commit.

       It is not possible to amend public changesets (see hg help  phases)  or
       changesets that have children.

       See hg help dates for a list of formats valid for -d/--date.

       Returns 0 on success, 1 if nothing changed.

       Examples:

       o commit	all files ending in .py:

	 hg commit --include "set:**.py"

       o commit	all non-binary files:

	 hg commit --exclude "set:binary()"

       o amend the current commit and set the date to now:

	 hg commit --amend --date now

       Options:

       -A, --addremove
	      mark new/missing files as	added/removed before committing

       --close-branch
	      mark a branch head as closed

       --amend
	      amend the	parent of the working directory

       -s, --secret
	      use the secret phase for committing

       -e, --edit
	      invoke editor on commit messages

       --force-close-branch
	      forcibly close branch from a non-head changeset (ADVANCED)

       -i, --interactive
	      use interactive mode

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

	  aliases: ci

   Change manipulation
   abort
       abort an	unfinished operation (EXPERIMENTAL):

       hg abort

       Aborts  a  multistep operation like graft, histedit, rebase, merge, and
       unshelve	if they	are in an unfinished state.

       use --dry-run/-n	to dry run the command.

       Options:

       -n, --dry-run
	      do not perform actions, just print output

   backout
       reverse effect of earlier changeset:

       hg backout [OPTION]... [-r] REV

       Prepare a new changeset with the	effect of REV undone  in  the  current
       working directory. If no	conflicts were encountered, it will be commit-
       ted immediately.

       If REV is the parent of the working directory, then this	new  changeset
       is committed automatically (unless --no-commit is specified).

       Note   hg backout cannot	be used	to fix either an unwanted or incorrect
	      merge.

       Examples:

       o Reverse the effect of the parent  of  the  working  directory.	  This
	 backout will be committed immediately:

	 hg backout -r .

       o Reverse the effect of previous	bad revision 23:

	 hg backout -r 23

       o Reverse  the effect of	previous bad revision 23 and leave changes un-
	 committed:

	 hg backout -r 23 --no-commit
	 hg commit -m "Backout revision	23"

       By default, the pending changeset will have one parent,	maintaining  a
       linear  history.	 With --merge, the pending changeset will instead have
       two parents: the	old parent of the working directory and	a new child of
       REV that	simply undoes REV.

       Before  version	1.7,  the  behavior  without --merge was equivalent to
       specifying --merge followed by hg update	--clean	. to cancel the	 merge
       and leave the child of REV as a head to be merged separately.

       See hg help dates for a list of formats valid for -d/--date.

       See  hg	help revert for	a way to restore files to the state of another
       revision.

       Returns 0 on success, 1 if nothing to backout or	there  are  unresolved
       files.

       Options:

       --merge
	      merge with old dirstate parent after backout

       --commit
	      commit if	no conflicts were encountered (DEPRECATED)

       --no-commit
	      do not commit

       --parent	_REV_
	      parent to	choose when backing out	merge (DEPRECATED)

       -r,--rev	<REV>
	      revision to backout

       -e, --edit
	      invoke editor on commit messages

       -t,--tool <TOOL>
	      specify merge tool

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       [+] marked option can be	specified multiple times

   continue
       resumes an interrupted operation	(EXPERIMENTAL):

       hg continue

       Finishes	a multistep operation like graft, histedit, rebase, merge, and
       unshelve	if they	are in an interrupted state.

       use --dry-run/-n	to dry run the command.

       Options:

       -n, --dry-run
	      do not perform actions, just print output

   graft
       copy changes from other branches	onto the current branch:

       hg graft	[OPTION]... [-r	REV]...	REV...

       This command uses Mercurial's merge logic to  copy  individual  changes
       from other branches without merging branches in the history graph. This
       is sometimes known as 'backporting' or  'cherry-picking'.  By  default,
       graft will copy user, date, and description from	the source changesets.

       Changesets  that	 are  ancestors	of the current revision, that have al-
       ready been grafted, or that are merges will be skipped.

       If --log	is specified, log messages will	have a comment appended	of the
       form:

       (grafted	from CHANGESETHASH)

       If --force is specified,	revisions will be grafted even if they are al-
       ready ancestors of, or have been	grafted	to, the	destination.  This  is
       useful when the revisions have since been backed	out.

       If a graft merge	results	in conflicts, the graft	process	is interrupted
       so that the current merge can be	manually resolved.  Once all conflicts
       are  addressed,	the  graft process can be continued with the -c/--con-
       tinue option.

       The -c/--continue option	reapplies all the earlier options.

       The --base option exposes more of how graft internally uses merge  with
       a  custom base revision.	--base can be used to specify another ancestor
       than the	first and only parent.

       The command:

       hg graft	-r 345 --base 234

       is thus pretty much the same as:

       hg diff -r 234 -r 345 | hg import

       but using merge to resolve conflicts and	track moved files.

       The result of a merge can thus be backported  as	 a  single  commit  by
       specifying  one	of  the	 merge	parents	 as base, and thus effectively
       grafting	the changes from the other side.

       It is also possible to collapse multiple	changesets and clean  up  his-
       tory  by	 specifying  another ancestor as base, much like rebase	--col-
       lapse --keep.

       The commit message can be tweaked after the fact	using commit --amend .

       For using non-ancestors as the base to backout changes, see the backout
       command and the hidden --parent option.

       Examples:

       o copy a	single change to the stable branch and edit its	description:

	 hg update stable
	 hg graft --edit 9393

       o graft a range of changesets with one exception, updating dates:

	 hg graft -D "2085::2093 and not 2091"

       o continue a graft after	resolving conflicts:

	 hg graft -c

       o show the source of a grafted changeset:

	 hg log	--debug	-r .

       o show revisions	sorted by date:

	 hg log	-r "sort(all(),	date)"

       o backport the result of	a merge	as a single commit:

	 hg graft -r 123 --base	123^

       o land a	feature	branch as one changeset:

	 hg up -cr default
	 hg graft -r featureX --base "ancestor('featureX', 'default')"

       See hg help revisions for more about specifying revisions.

       Returns 0 on successful completion.

       Options:

       -r,--rev	<REV[+]>
	      revisions	to graft

       --base _REV_
	      base revision when doing the graft merge (ADVANCED)

       -c, --continue
	      resume interrupted graft

       --stop stop interrupted graft

       --abort
	      abort interrupted	graft

       -e, --edit
	      invoke editor on commit messages

       --log  append graft info	to log message

       --no-commit
	      don't commit, just apply the changes in working directory

       -f, --force
	      force graft

       -D, --currentdate
	      record the current date as commit	date

       -U, --currentuser
	      record the current user as committer

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -t,--tool <TOOL>
	      specify merge tool

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

   merge
       merge another revision into working directory:

       hg merge	[-P] [[-r] REV]

       The  current  working directory is updated with all changes made	in the
       requested revision since	the last common	predecessor revision.

       Files that changed between either parent	are marked as changed for  the
       next  commit  and a commit must be performed before any further updates
       to the repository are allowed. The next commit will have	two parents.

       --tool can be used to specify the merge tool used for file  merges.  It
       overrides  the  HGMERGE	environment  variable  and  your configuration
       files. See hg help merge-tools for options.

       If no revision is specified, the	working	directory's parent is  a  head
       revision,  and  the current branch contains exactly one other head, the
       other head is merged with by default. Otherwise,	an  explicit  revision
       with which to merge must	be provided.

       See hg help resolve for information on handling file conflicts.

       To undo an uncommitted merge, use hg merge --abort which	will check out
       a clean copy of the original merge parent, losing all changes.

       Returns 0 on success, 1 if there	are unresolved files.

       Options:

       -f, --force
	      force a merge including outstanding changes (DEPRECATED)

       -r,--rev	<REV>
	      revision to merge

       -P, --preview
	      review revisions to merge	(no merge is performed)

       --abort
	      abort the	ongoing	merge

       -t,--tool <TOOL>
	      specify merge tool

   Change organization
   bookmarks
       create a	new bookmark or	list existing bookmarks:

       hg bookmarks [OPTIONS]... [NAME]...

       Bookmarks are labels on changesets to help track	lines of  development.
       Bookmarks  are  unversioned  and	 can  be  moved,  renamed and deleted.
       Deleting	or moving a bookmark has no effect on the  associated  change-
       sets.

       Creating	 or updating to	a bookmark causes it to	be marked as 'active'.
       The active bookmark is indicated	with a '*'.  When a  commit  is	 made,
       the  active bookmark will advance to the	new commit.  A plain hg	update
       will also advance an active bookmark, if	possible.  Updating away  from
       a bookmark will cause it	to be deactivated.

       Bookmarks  can  be  pushed and pulled between repositories (see hg help
       push and	hg help	pull). If a shared bookmark has	diverged, a  new  'di-
       vergent	bookmark'  of  the  form 'name@path' will be created. Using hg
       merge will resolve the divergence.

       Specifying bookmark as '.' to -m/-d/-l options is equivalent to	speci-
       fying the active	bookmark's name.

       A  bookmark named '@' has the special property that hg clone will check
       it out by default if it exists.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions such as {bookmark}. See also hg help templates.

       active Boolean. True if the bookmark is active.

       Examples:

       o create	an active bookmark for a new line of development:

	 hg book new-feature

       o create	an inactive bookmark as	a place	marker:

	 hg book -i reviewed

       o create	an inactive bookmark on	another	changeset:

	 hg book -r .^ tested

       o rename	bookmark turkey	to dinner:

	 hg book -m turkey dinner

       o move the '@' bookmark from another branch:

	 hg book -f @

       o print only the	active bookmark	name:

	 hg book -ql .

       Options:

       -f, --force
	      force

       -r,--rev	<REV>
	      revision for bookmark action

       -d, --delete
	      delete a given bookmark

       -m,--rename <OLD>
	      rename a given bookmark

       -i, --inactive
	      mark a bookmark inactive

       -l, --list
	      list existing bookmarks

       -T,--template <TEMPLATE>
	      display with template

	      aliases: bookmark

   branch
       set or show the current branch name:

       hg branch [-fC] [NAME]

       Note   Branch names are permanent and global. Use hg bookmark to	create
	      a	light-weight bookmark instead. See hg help  glossary for  more
	      information about	named branches and bookmarks.

       With  no	argument, show the current branch name.	With one argument, set
       the working directory branch name (the branch will  not	exist  in  the
       repository  until  the  next commit). Standard practice recommends that
       primary development take	place on the 'default' branch.

       Unless -f/--force is specified, branch will not let you	set  a	branch
       name that already exists.

       Use  -C/--clean	to  reset  the working directory branch	to that	of the
       parent of the working directory,	negating a previous branch change.

       Use the command hg update to switch to an existing branch. Use hg  com-
       mit  --close-branch to mark this	branch head as closed.	When all heads
       of a branch are closed, the branch will be considered closed.

       Returns 0 on success.

       Options:

       -f, --force
	      set branch name even if it shadows an existing branch

       -C, --clean
	      reset branch name	to parent branch name

       -r,--rev	<VALUE[+]>
	      change branches of the given revs	(EXPERIMENTAL)

       [+] marked option can be	specified multiple times

   branches
       list repository named branches:

       hg branches [-c]

       List the	repository's named branches, indicating	which ones  are	 inac-
       tive.  If  -c/--closed is specified, also list branches which have been
       marked closed (see hg commit --close-branch).

       Use the command hg update to switch to an existing branch.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions such as {branch}.	See also hg help templates.

       active Boolean. True if the branch is active.

       closed Boolean. True if the branch is closed.

       current
	      Boolean. True if it is the current branch.

       Returns 0.

       Options:

       -a, --active
	      show only	branches that have unmerged heads (DEPRECATED)

       -c, --closed
	      show normal and closed branches

       -r,--rev	<VALUE[+]>
	      show branch name(s) of the given rev

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

   phase
       set or show the current phase name:

       hg phase	[-p|-d|-s] [-f]	[-r] [REV...]

       With no argument, show the phase	name of	the current revision(s).

       With  one  of  -p/--public, -d/--draft or -s/--secret, change the phase
       value of	the specified revisions.

       Unless -f/--force is specified, hg phase	won't move changesets  from  a
       lower phase to a	higher phase. Phases are ordered as follows:

       public <	draft <	secret

       Returns 0 on success, 1 if some phases could not	be changed.

       (For more information about the phases concept, see hg help phases.)

       Options:

       -p, --public
	      set changeset phase to public

       -d, --draft
	      set changeset phase to draft

       -s, --secret
	      set changeset phase to secret

       -f, --force
	      allow to move boundary backward

       -r,--rev	<REV[+]>
	      target revision

       [+] marked option can be	specified multiple times

   tag
       add one or more tags for	the current or given revision:

       hg tag [-f] [-l]	[-m TEXT] [-d DATE] [-u	USER] [-r REV] NAME...

       Name a particular revision using	<name>.

       Tags  are  used	to name	particular revisions of	the repository and are
       very useful to compare different	revisions, to go back  to  significant
       earlier versions	or to mark branch points as releases, etc. Changing an
       existing	tag is normally	disallowed; use	-f/--force to override.

       If no revision is given,	the parent of the working directory is used.

       To facilitate version control, distribution, and	merging	of tags,  they
       are  stored  as	a  file	 named ".hgtags" which is managed similarly to
       other project files and can be  hand-edited  if	necessary.  This  also
       means  that  tagging  creates a new commit. The file ".hg/localtags" is
       used for	local tags (not	shared among repositories).

       Tag commits are usually made at the head	of a branch. If	the parent  of
       the  working  directory	is  not	 a  branch  head,  hg  tag aborts; use
       -f/--force to force the tag commit to be	based on a non-head changeset.

       See hg help dates for a list of formats valid for -d/--date.

       Since tag names have priority over branch names during revision lookup,
       using an	existing branch	name as	a tag name is discouraged.

       Returns 0 on success.

       Options:

       -f, --force
	      force tag

       -l, --local
	      make the tag local

       -r,--rev	<REV>
	      revision to tag

       --remove
	      remove a tag

       -e, --edit
	      invoke editor on commit messages

       -m,--message <TEXT>
	      use text as commit message

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

   tags
       list repository tags:

       hg tags

       This lists both regular and local tags. When the	-v/--verbose switch is
       used, a third column "local" is	printed	 for  local  tags.   When  the
       -q/--quiet switch is used, only the tag name is printed.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions such as {tag}. See also hg help templates.

       type   String. local for	local tags.

       Returns 0 on success.

       Options:

       -T,--template <TEMPLATE>
	      display with template

   File	content	management
   annotate
       show changeset information by line for each file:

       hg annotate [-r REV] [-f] [-a] [-u] [-d]	[-n] [-c] [-l] FILE...

       List changes in files, showing the revision  id	responsible  for  each
       line.

       This  command  is  useful for discovering when a	change was made	and by
       whom.

       If you include --file, --user, or --date, the revision number  is  sup-
       pressed unless you also include --number.

       Without	the  -a/--text option, annotate	will avoid processing files it
       detects as binary. With -a, annotate will annotate the file anyway, al-
       though the results will probably	be neither useful nor desirable.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       lines  List of lines with annotation data.

       path   String. Repository-absolute path of the specified	file.

       And each	entry of {lines} provides the following	sub-keywords in	 addi-
       tion to {date}, {node}, {rev}, {user}, etc.

       line   String. Line content.

       lineno Integer. Line number at that revision.

       path   String. Repository-absolute path of the file at that revision.

       See hg help templates.operators for the list expansion syntax.

       Returns 0 on success.

       Options:

       -r,--rev	<REV>
	      annotate the specified revision

       --follow
	      follow copies/renames and	list the filename (DEPRECATED)

       --no-follow
	      don't follow copies and renames

       -a, --text
	      treat all	files as text

       -u, --user
	      list the author (long with -v)

       -f, --file
	      list the filename

       -d, --date
	      list the date (short with	-q)

       -n, --number
	      list the revision	number (default)

       -c, --changeset
	      list the changeset

       -l, --line-number
	      show line	number at the first appearance

       --skip _REV[+]_
	      revision to not display (EXPERIMENTAL)

       -w, --ignore-all-space
	      ignore white space when comparing	lines

       -b, --ignore-space-change
	      ignore changes in	the amount of white space

       -B, --ignore-blank-lines
	      ignore changes whose lines are all blank

       -Z, --ignore-space-at-eol
	      ignore changes in	whitespace at EOL

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

	  aliases: blame

   cat
       output the current or given revision of files:

       hg cat [OPTION]... FILE...

       Print the specified files as they were at the given revision. If	no re-
       vision is given,	the parent of the working directory is used.

       Output may be to	a file,	in which case the name of the  file  is	 given
       using a template	string.	See hg help templates. In addition to the com-
       mon template keywords, the following formatting rules are supported:

       %%

	      literal "%" character

       %s

	      basename of file being printed

       %d

	      dirname of file being printed, or	'.' if in repository root

       %p

	      root-relative path name of file being printed

       %H

	      changeset	hash (40 hexadecimal digits)

       %R

	      changeset	revision number

       %h

	      short-form changeset hash	(12 hexadecimal	digits)

       %r

	      zero-padded changeset revision number

       %b

	      basename of the exporting	repository

       \

	      literal "" character

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       data   String. File content.

       path   String. Repository-absolute path of the file.

       Returns 0 on success.

       Options:

       -o,--output <FORMAT>
	      print output to file with	formatted name

       -r,--rev	<REV>
	      print the	given revision

       --decode
	      apply any	matching decode	filter

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

   copy
       mark files as copied for	the next commit:

       hg copy [OPTION]... SOURCE... DEST

       Mark  dest  as  having  copies of source	files. If dest is a directory,
       copies are put in that directory. If dest is a file, the	source must be
       a single	file.

       By  default, this command copies	the contents of	files as they exist in
       the working directory. If invoked with  -A/--after,  the	 operation  is
       recorded, but no	copying	is performed.

       This  command  takes effect with	the next commit. To undo a copy	before
       that, see hg revert.

       Returns 0 on success, 1 if errors are encountered.

       Options:

       -A, --after
	      record a copy that has already occurred

       -f, --force
	      forcibly copy over an existing managed file

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

	  aliases: cp

   diff
       diff repository (or selected files):

       hg diff [OPTION]... ([-c	REV] | [-r REV1	[-r REV2]]) [FILE]...

       Show differences	between	revisions for the specified files.

       Differences between files are shown using the unified diff format.

       Note   hg diff may generate unexpected results for merges, as  it  will
	      default  to comparing against the	working	directory's first par-
	      ent changeset if no revisions are	specified.

       When two	revision arguments are given, then changes are	shown  between
       those  revisions.  If only one revision is specified then that revision
       is compared to the working directory, and, when no revisions are	speci-
       fied, the working directory files are compared to its first parent.

       Alternatively  you  can	specify	-c/--change with a revision to see the
       changes in that changeset relative to its first parent.

       Without the -a/--text option, diff will avoid generating	diffs of files
       it detects as binary. With -a, diff will	generate a diff	anyway,	proba-
       bly with	undesirable results.

       Use the -g/--git	option to generate diffs in the	git extended diff for-
       mat. For	more information, read hg help diffs.

       Examples:

       o compare a file	in the current working directory to its	parent:

	 hg diff foo.c

       o compare two historical	versions of a directory, with rename info:

	 hg diff --git -r 1.0:1.2 lib/

       o get change stats relative to the last change on some date:

	 hg diff --stat	-r "date('may 2')"

       o diff all newly-added files that contain a keyword:

	 hg diff "set:added() and grep(GNU)"

       o compare a revision and	its parents:

	 hg diff -c 9353	 # compare against first parent
	 hg diff -r 9353^:9353	 # same	using revset syntax
	 hg diff -r 9353^2:9353	 # compare against the second parent

       Returns 0 on success.

       Options:

       -r,--rev	<REV[+]>
	      revision

       -c,--change <REV>
	      change made by revision

       -a, --text
	      treat all	files as text

       -g, --git
	      use git extended diff format

       --binary
	      generate binary diffs in git mode	(default)

       --nodates
	      omit dates from diff headers

       --noprefix
	      omit a/ and b/ prefixes from filenames

       -p, --show-function
	      show which function each change is in

       --reverse
	      produce a	diff that undoes the changes

       -w, --ignore-all-space
	      ignore white space when comparing	lines

       -b, --ignore-space-change
	      ignore changes in	the amount of white space

       -B, --ignore-blank-lines
	      ignore changes whose lines are all blank

       -Z, --ignore-space-at-eol
	      ignore changes in	whitespace at EOL

       -U,--unified <NUM>
	      number of	lines of context to show

       --stat output diffstat-style summary of changes

       --root _DIR_
	      produce diffs relative to	subdirectory

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

   grep
       search revision history for a pattern in	specified files:

       hg grep [OPTION]... PATTERN [FILE]...

       Search revision history for a regular expression	in the specified files
       or the entire project.

       By default, grep	prints the most	recent revision	number for  each  file
       in  which it finds a match. To get it to	print every revision that con-
       tains a change in  match	 status	 ("-"  for  a  match  that  becomes  a
       non-match, or "+" for a non-match that becomes a	match),	use the	--diff
       flag.

       PATTERN can be any Python (roughly Perl-compatible) regular expression.

       If no FILEs are specified (and -f/--follow isn't	set), all files	in the
       repository  are	searched, including those that don't exist in the cur-
       rent branch or have been	deleted	in a prior changeset.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       change String.  Character denoting insertion + or removal -.  Available
	      if --diff	is specified.

       lineno Integer. Line number of the match.

       path   String. Repository-absolute path of the file.

       texts  List of text chunks.

       And each	entry of {texts} provides the following	sub-keywords.

       matched
	      Boolean. True if the chunk matches the specified pattern.

       text   String. Chunk content.

       See hg help templates.operators for the list expansion syntax.

       Returns 0 if a match is found, 1	otherwise.

       Options:

       -0, --print0
	      end fields with NUL

       --all  print all	revisions that match (DEPRECATED)

       --diff print all	revisions when the term	was introduced or removed

       -a, --text
	      treat all	files as text

       -f, --follow
	      follow changeset history,	or file	history	across copies and  re-
	      names

       -i, --ignore-case
	      ignore case when matching

       -l, --files-with-matches
	      print only filenames and revisions that match

       -n, --line-number
	      print matching line numbers

       -r,--rev	<REV[+]>
	      only search files	changed	within revision	range

       --all-files
	      include all files	in the changeset while grepping	(EXPERIMENTAL)

       -u, --user
	      list the author (long with -v)

       -d, --date
	      list the date (short with	-q)

       -T,--template <TEMPLATE>
	      display with template

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   Change navigation
   bisect
       subdivision search of changesets:

       hg bisect [-gbsr] [-U] [-c CMD] [REV]

       This command helps to find changesets which introduce problems. To use,
       mark the	earliest changeset you know exhibits the problem as bad,  then
       mark  the  latest changeset which is free from the problem as good. Bi-
       sect will update	your working directory to a revision for testing  (un-
       less  the  -U/--noupdate	 option	is specified). Once you	have performed
       tests, mark the working directory as good or bad, and bisect  will  ei-
       ther  update  to	 another  candidate  changeset or announce that	it has
       found the bad revision.

       As a shortcut, you can also use the revision argument to	mark  a	 revi-
       sion as good or bad without checking it out first.

       If  you supply a	command, it will be used for automatic bisection.  The
       environment variable HG_NODE will contain the ID	of the changeset being
       tested.	The  exit status of the	command	will be	used to	mark revisions
       as good or bad: status 0	means good, 125	means to  skip	the  revision,
       127  (command  not  found)  will	 abort	the  bisection,	 and any other
       non-zero	exit status means the revision is bad.

       Some examples:

       o start a bisection with	known bad revision 34, and good	revision 12:

	 hg bisect --bad 34
	 hg bisect --good 12

       o advance the current bisection by marking current revision as good  or
	 bad:

	 hg bisect --good
	 hg bisect --bad

       o mark  the  current revision, or a known revision, to be skipped (e.g.
	 if that revision is not usable	because	of another issue):

	 hg bisect --skip
	 hg bisect --skip 23

       o skip all revisions that do not	touch directories foo or bar:

	 hg bisect --skip "!( file('path:foo') & file('path:bar') )"

       o forget	the current bisection:

	 hg bisect --reset

       o use 'make && make tests' to automatically find	the first broken revi-
	 sion:

	 hg bisect --reset
	 hg bisect --bad 34
	 hg bisect --good 12
	 hg bisect --command "make && make tests"

       o see  all changesets whose states are already known in the current bi-
	 section:

	 hg log	-r "bisect(pruned)"

       o see the changeset currently being bisected (especially	useful if run-
	 ning with -U/--noupdate):

	 hg log	-r "bisect(current)"

       o see all changesets that took part in the current bisection:

	 hg log	-r "bisect(range)"

       o you can even get a nice graph:

	 hg log	--graph	-r "bisect(range)"

       See hg help revisions.bisect for	more about the bisect()	predicate.

       Returns 0 on success.

       Options:

       -r, --reset
	      reset bisect state

       -g, --good
	      mark changeset good

       -b, --bad
	      mark changeset bad

       -s, --skip
	      skip testing changeset

       -e, --extend
	      extend the bisect	range

       -c,--command <CMD>
	      use command to check changeset state

       -U, --noupdate
	      do not update to target

   heads
       show branch heads:

       hg heads	[-ct] [-r STARTREV] [REV]...

       With  no	 arguments,  show  all	open  branch  heads in the repository.
       Branch heads are	changesets  that  have	no  descendants	 on  the  same
       branch.	They  are  where development generally takes place and are the
       usual targets for update	and merge operations.

       If one or more REVs are given, only open	branch heads on	 the  branches
       associated with the specified changesets	are shown. This	means that you
       can use hg heads	. to  see  the	heads  on  the	currently  checked-out
       branch.

       If  -c/--closed is specified, also show branch heads marked closed (see
       hg commit --close-branch).

       If STARTREV is specified, only those  heads  that  are  descendants  of
       STARTREV	will be	displayed.

       If  -t/--topo  is specified, named branch mechanics will	be ignored and
       only topological	heads (changesets with no children) will be shown.

       Returns 0 if matching heads are found, 1	if not.

       Options:

       -r,--rev	<STARTREV>
	      show only	heads which are	descendants of STARTREV

       -t, --topo
	      show topological heads only

       -a, --active
	      show active branchheads only (DEPRECATED)

       -c, --closed
	      show normal and closed branch heads

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

   identify
       identify	the working directory or specified revision:

       hg identify [-nibtB] [-r	REV] [SOURCE]

       Print a summary identifying the repository state	at REV	using  one  or
       two parent hash identifiers, followed by	a "+" if the working directory
       has uncommitted changes,	the branch name	(if not	default),  a  list  of
       tags, and a list	of bookmarks.

       When  REV  is  not  given,  print a summary of the current state	of the
       repository including the	working	directory. Specify -r. to get informa-
       tion  of	 the  working  directory  parent  without scanning uncommitted
       changes.

       Specifying a path to a repository root or Mercurial bundle  will	 cause
       lookup to operate on that repository/bundle.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       dirty  String. Character	+ denoting if the working directory has	uncom-
	      mitted changes.

       id     String. One or two nodes,	optionally followed by +.

       parents
	      List of strings. Parent nodes of the changeset.

       Examples:

       o generate a build identifier for the working directory:

	 hg id --id > build-id.dat

       o find the revision corresponding to a tag:

	 hg id -n -r 1.3

       o check the most	recent revision	of a remote repository:

	 hg id -r tip https://www.mercurial-scm.org/repo/hg/

       See  hg	log for	 generating more information about specific revisions,
       including full hash identifiers.

       Returns 0 if successful.

       Options:

       -r,--rev	<REV>
	      identify the specified revision

       -n, --num
	      show local revision number

       -i, --id
	      show global revision id

       -b, --branch
	      show branch

       -t, --tags
	      show tags

       -B, --bookmarks
	      show bookmarks

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       -T,--template <TEMPLATE>
	      display with template

	      aliases: id

   log
       show revision history of	entire repository or files:

       hg log [OPTION]... [FILE]

       Print the revision  history  of	the  specified	files  or  the	entire
       project.

       If no revision range is specified, the default is tip:0 unless --follow
       is set, in which	case the working  directory  parent  is	 used  as  the
       starting	revision.

       File  history  is  shown	 without  following  rename or copy history of
       files. Use -f/--follow with a filename to follow	history	across renames
       and copies. --follow without a filename will only show ancestors	of the
       starting	revision.

       By default this command prints revision number and changeset id,	 tags,
       non-trivial  parents,  user, date and time, and a summary for each com-
       mit. When the -v/--verbose switch is used, the list  of	changed	 files
       and full	commit message are shown.

       With  --graph the revisions are shown as	an ASCII art DAG with the most
       recent changeset	at the top.  'o' is a changeset, '@' is	a working  di-
       rectory	parent,	'_' closes a branch, 'x' is obsolete, '*' is unstable,
       and '+' represents a fork where the changeset from the lines below is a
       parent  of the 'o' merge	on the same line.  Paths in the	DAG are	repre-
       sented with '|',	'/' and	so forth. ':' in place of a '|'	indicates  one
       or more revisions in a path are omitted.

       Use  -L/--line-range  FILE,M:N  options	to follow the history of lines
       from M to N in FILE. With -p/--patch only diff hunks  affecting	speci-
       fied line range will be shown. This option requires --follow; it	can be
       specified multiple times. Currently, this option	is not compatible with
       --graph.	This option is experimental.

       Note   hg  log  --patch may  generate  unexpected diff output for merge
	      changesets, as it	will only compare the merge changeset  against
	      its  first  parent. Also,	only files different from BOTH parents
	      will appear in files:.

       Note   For performance reasons, hg log FILE may omit duplicate  changes
	      made  on branches	and will not show removals or mode changes. To
	      see all such changes, use	the --removed switch.

       Note   The history resulting from -L/--line-range  options  depends  on
	      diff  options; for instance if white-spaces are ignored, respec-
	      tive changes with	only white-spaces in specified line range will
	      not be listed.

       Some examples:

       o changesets with full descriptions and file lists:

	 hg log	-v

       o changesets ancestral to the working directory:

	 hg log	-f

       o last 10 commits on the	current	branch:

	 hg log	-l 10 -b .

       o changesets showing all	modifications of a file, including removals:

	 hg log	--removed file.c

       o all changesets	that touch a directory,	with diffs, excluding merges:

	 hg log	-Mp lib/

       o all revision numbers that match a keyword:

	 hg log	-k bug --template "{rev}\n"

       o the full hash identifier of the working directory parent:

	 hg log	-r . --template	"{node}\n"

       o list available	log templates:

	 hg log	-T list

       o check if a given changeset is included	in a tagged release:

	 hg log	-r "a21ccf and ancestor(1.9)"

       o find all changesets by	some user in a date range:

	 hg log	-k alice -d "may 2008 to jul 2008"

       o summary of all	changesets after the last tag:

	 hg log	-r "last(tagged())::" --template "{desc|firstline}\n"

       o changesets touching lines 13 to 23 for	file.c:

	 hg log	-L file.c,13:23

       o changesets  touching  lines  13  to 23	for file.c and lines 2 to 6 of
	 main.c	with patch:

	 hg log	-L file.c,13:23	-L main.c,2:6 -p

       See hg help dates for a list of formats valid for -d/--date.

       See hg help revisions for more about specifying and ordering revisions.

       See hg help templates for more about pre-packaged styles	and specifying
       custom  templates.  The default template	used by	the log	command	can be
       customized via the ui.logtemplate configuration setting.

       Returns 0 on success.

       Options:

       -f, --follow
	      follow changeset history,	or file	history	across copies and  re-
	      names

       --follow-first
	      only follow the first parent of merge changesets (DEPRECATED)

       -d,--date <DATE>
	      show revisions matching date spec

       -C, --copies
	      show copied files

       -k,--keyword <TEXT[+]>
	      do case-insensitive search for a given text

       -r,--rev	<REV[+]>
	      show the specified revision or revset

       -L,--line-range <FILE,RANGE[+]>
	      follow line range	of specified file (EXPERIMENTAL)

       --removed
	      include revisions	where files were removed

       -m, --only-merges
	      show only	merges (DEPRECATED) (use -r "merge()" instead)

       -u,--user <USER[+]>
	      revisions	committed by user

       --only-branch _BRANCH[+]_
	      show only	changesets within the given named branch (DEPRECATED)

       -b,--branch <BRANCH[+]>
	      show changesets within the given named branch

       -P,--prune <REV[+]>
	      do not display revision or any of	its ancestors

       -p, --patch
	      show patch

       -g, --git
	      use git extended diff format

       -l,--limit <NUM>
	      limit number of changes displayed

       -M, --no-merges
	      do not show merges

       --stat output diffstat-style summary of changes

       -G, --graph
	      show the revision	DAG

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

	  aliases: history

   parents
       show the	parents	of the working directory or revision (DEPRECATED):

       hg parents [-r REV] [FILE]

       Print  the working directory's parent revisions.	If a revision is given
       via -r/--rev, the parent	of that	revision will be printed.  If  a  file
       argument	is given, the revision in which	the file was last changed (be-
       fore the	working	directory revision or the argument to --rev if	given)
       is printed.

       This command is equivalent to:

       hg log -r "p1()+p2()" or
       hg log -r "p1(REV)+p2(REV)" or
       hg log -r "max(::p1() and file(FILE))+max(::p2()	and file(FILE))" or
       hg log -r "max(::p1(REV)	and file(FILE))+max(::p2(REV) and file(FILE))"

       See hg summary and hg help revsets for related information.

       Returns 0 on success.

       Options:

       -r,--rev	<REV>
	      show parents of the specified revision

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

   tip
       show the	tip revision (DEPRECATED):

       hg tip [-p] [-g]

       The  tip	 revision  (usually just called	the tip) is the	changeset most
       recently	added to the  repository  (and	therefore  the	most  recently
       changed head).

       If  you	have  just  made a commit, that	commit will be the tip.	If you
       have just pulled	changes	from  another  repository,  the	 tip  of  that
       repository becomes the current tip. The "tip" tag is special and	cannot
       be renamed or assigned to a different changeset.

       This command is deprecated, please use hg heads instead.

       Returns 0 on success.

       Options:

       -p, --patch
	      show patch

       -g, --git
	      use git extended diff format

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

   Working directory management
   add
       add the specified files on the next commit:

       hg add [OPTION]... [FILE]...

       Schedule	files to be version controlled and added to the	repository.

       The files will be added to the repository at the	next commit.  To  undo
       an add before that, see hg forget.

       If  no  names  are given, add all files to the repository (except files
       matching	.hgignore).

       Examples:

	  o New	(unknown) files	are added automatically	by hg add:

	    $ ls
	    foo.c
	    $ hg status
	    ? foo.c
	    $ hg add
	    adding foo.c
	    $ hg status
	    A foo.c

	  o Specific files to be added can be specified:

	    $ ls
	    bar.c  foo.c
	    $ hg status
	    ? bar.c
	    ? foo.c
	    $ hg add bar.c
	    $ hg status
	    A bar.c
	    ? foo.c

       Returns 0 if all	files are successfully added.

       Options:

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -S, --subrepos
	      recurse into subrepositories

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

   addremove
       add all new files, delete all missing files:

       hg addremove [OPTION]...	[FILE]...

       Add all new files and remove all	missing	files from the repository.

       Unless names are	given, new files are ignored if	they match any of  the
       patterns	 in  .hgignore.	 As with add, these changes take effect	at the
       next commit.

       Use the -s/--similarity option to detect	 renamed  files.  This	option
       takes  a	percentage between 0 (disabled)	and 100	(files must be identi-
       cal) as its parameter. With a parameter greater than 0,	this  compares
       every  removed  file  with  every  added	file and records those similar
       enough as renames. Detecting renamed files this way can	be  expensive.
       After  using this option, hg status -C can be used to check which files
       were identified as moved	or renamed. If not specified,  -s/--similarity
       defaults	to 100 and only	renames	of identical files are detected.

       Examples:

	  o A  number  of  files (bar.c	and foo.c) are new, while foobar.c has
	    been removed (without using	hg remove) from	the repository:

	    $ ls
	    bar.c foo.c
	    $ hg status
	    ! foobar.c
	    ? bar.c
	    ? foo.c
	    $ hg addremove
	    adding bar.c
	    adding foo.c
	    removing foobar.c
	    $ hg status
	    A bar.c
	    A foo.c
	    R foobar.c

	  o A file foobar.c was	moved to foo.c without using hg	 rename.   Af-
	    terwards, it was edited slightly:

	    $ ls
	    foo.c
	    $ hg status
	    ! foobar.c
	    ? foo.c
	    $ hg addremove --similarity	90
	    removing foobar.c
	    adding foo.c
	    recording removal of foobar.c as rename to foo.c (94% similar)
	    $ hg status	-C
	    A foo.c
	      foobar.c
	    R foobar.c

       Returns 0 if all	files are successfully added.

       Options:

       -s,--similarity <SIMILARITY>
	      guess renamed files by similarity	(0<=s<=100)

       -S, --subrepos
	      recurse into subrepositories

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

   files
       list tracked files:

       hg files	[OPTION]... [FILE]...

       Print  files under Mercurial control in the working directory or	speci-
       fied revision for given files (excluding	removed	files).	 Files can  be
       specified as filenames or filesets.

       If  no  files  are given	to match, this command prints the names	of all
       files under Mercurial control.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       flags  String. Character	denoting file's	symlink	and executable bits.

       path   String. Repository-absolute path of the file.

       size   Integer. Size of the file	in bytes.

       Examples:

       o list all files	under the current directory:

	 hg files .

       o shows sizes and flags for current revision:

	 hg files -vr .

       o list all files	named README:

	 hg files -I "**/README"

       o list all binary files:

	 hg files "set:binary()"

       o find files containing a regular expression:

	 hg files "set:grep('bob')"

       o search	tracked	file contents with xargs and grep:

	 hg files -0 | xargs -0	grep foo

       See hg help patterns and	hg help	filesets for more information on spec-
       ifying file patterns.

       Returns 0 if a match is found, 1	otherwise.

       Options:

       -r,--rev	<REV>
	      search the repository as it is in	REV

       -0, --print0
	      end filenames with NUL, for use with xargs

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -T,--template <TEMPLATE>
	      display with template

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

   forget
       forget the specified files on the next commit:

       hg forget [OPTION]... FILE...

       Mark the	specified files	so they	will no	longer be  tracked  after  the
       next commit.

       This  only  removes  files from the current branch, not from the	entire
       project history,	and it does not	delete them from  the  working	direc-
       tory.

       To delete the file from the working directory, see hg remove.

       To undo a forget	before the next	commit,	see hg add.

       Examples:

       o forget	newly-added binary files:

	 hg forget "set:added()	and binary()"

       o forget	files that would be excluded by	.hgignore:

	 hg forget "set:hgignore()"

       Returns 0 on success.

       Options:

       -i, --interactive
	      use interactive mode

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

   locate
       locate files matching specific patterns (DEPRECATED):

       hg locate [OPTION]... [PATTERN]...

       Print  files  under  Mercurial  control	in the working directory whose
       names match the given patterns.

       By default, this	command	searches all directories in the	working	direc-
       tory.  To search	just the current directory and its subdirectories, use
       "--include .".

       If no patterns are given	to match, this command prints the names	of all
       files under Mercurial control in	the working directory.

       If  you	want  to feed the output of this command into the "xargs" com-
       mand, use the -0	option to both this command  and  "xargs".  This  will
       avoid  the  problem  of	"xargs"	treating single	filenames that contain
       whitespace as multiple filenames.

       See hg help files for a more versatile command.

       Returns 0 if a match is found, 1	otherwise.

       Options:

       -r,--rev	<REV>
	      search the repository as it is in	REV

       -0, --print0
	      end filenames with NUL, for use with xargs

       -f, --fullpath
	      print complete paths from	the filesystem root

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   remove
       remove the specified files on the next commit:

       hg remove [OPTION]... FILE...

       Schedule	the indicated files for	removal	from the current branch.

       This command schedules the files	to be removed at the next commit.   To
       undo  a	remove before that, see	hg revert. To undo added files,	see hg
       forget.

       -A/--after can be used to remove	only  files  that  have	 already  been
       deleted,	 -f/--force can	be used	to force deletion, and -Af can be used
       to remove files from the	next revision without deleting them  from  the
       working directory.

       The  following  table details the behavior of remove for	different file
       states (columns)	and option combinations	(rows).	The  file  states  are
       Added  [A], Clean [C], Modified [M] and Missing [!]  (as	reported by hg
       status).	The actions are	Warn, Remove (from branch)  and	 Delete	 (from
       disk):

			    +----------+---+----+----+---+
			    |opt/state | A | C	| M  | ! |
			    +----------+---+----+----+---+
			    |none      | W | RD	| W  | R |
			    +----------+---+----+----+---+
			    |-f	       | R | RD	| RD | R |
			    +----------+---+----+----+---+
			    |-A	       | W | W	| W  | R |
			    +----------+---+----+----+---+
			    |-Af       | R | R	| R  | R |
			    +----------+---+----+----+---+

       Note   hg  remove never deletes files in	Added [A] state	from the work-
	      ing directory, not even if --force is specified.

       Returns 0 on success, 1 if any warnings encountered.

       Options:

       -A, --after
	      record delete for	missing	files

       -f, --force
	      forget added files, delete modified files

       -S, --subrepos
	      recurse into subrepositories

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

	  aliases: rm

   rename
       rename files; equivalent	of copy	+ remove:

       hg rename [OPTION]... SOURCE... DEST

       Mark dest as copies of sources; mark sources for	deletion. If dest is a
       directory,  copies  are put in that directory. If dest is a file, there
       can only	be one source.

       By default, this	command	copies the contents of files as	they exist  in
       the  working  directory.	 If  invoked with -A/--after, the operation is
       recorded, but no	copying	is performed.

       This command takes effect at the	next commit. To	undo a	rename	before
       that, see hg revert.

       Returns 0 on success, 1 if errors are encountered.

       Options:

       -A, --after
	      record a rename that has already occurred

       -f, --force
	      forcibly move over an existing managed file

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

	  aliases: move	mv

   resolve
       redo merges or set/view the merge status	of files:

       hg resolve [OPTION]... [FILE]...

       Merges  with  unresolved	conflicts are often the	result of non-interac-
       tive merging using the internal:merge configuration setting, or a  com-
       mand-line  merge	tool like diff3. The resolve command is	used to	manage
       the files involved in a merge, after hg merge has been run, and	before
       hg  commit is  run  (i.e. the working directory must have two parents).
       See hg help merge-tools for information on configuring merge tools.

       The resolve command can be used in the following	ways:

       o hg resolve [--re-merge] [--tool TOOL] FILE...:	 attempt  to  re-merge
	 the specified files, discarding any previous merge attempts. Re-merg-
	 ing is	not performed  for  files  already  marked  as	resolved.  Use
	 --all/-a  to select all unresolved files. --tool can be used to spec-
	 ify the merge tool used for the given files. It overrides the HGMERGE
	 environment  variable	and  your  configuration files.	 Previous file
	 contents are saved with a .orig suffix.

       o hg resolve -m [FILE]: mark a file as having been resolved (e.g. after
	 having	manually fixed-up the files). The default is to	mark all unre-
	 solved	files.

       o hg resolve -u [FILE]...: mark a file as unresolved. The default is to
	 mark all resolved files.

       o hg  resolve -l: list files which had or still have conflicts.	In the
	 printed list, U = unresolved and R = resolved.	 You can use set:unre-
	 solved()  or  set:resolved() to filter	the list. See hg help filesets
	 for details.

       Note   Mercurial	will not let you commit	files  with  unresolved	 merge
	      conflicts.  You must use hg resolve -m ... before	you can	commit
	      after a conflicting merge.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       mergestatus
	      String. Character	denoting merge conflicts, U or R.

       path   String. Repository-absolute path of the file.

       Returns 0 on success, 1 if any files fail a resolve attempt.

       Options:

       -a, --all
	      select all unresolved files

       -l, --list
	      list state of files needing merge

       -m, --mark
	      mark files as resolved

       -u, --unmark
	      mark files as unresolved

       -n, --no-status
	      hide status prefix

       --re-merge
	      re-merge files

       -t,--tool <TOOL>
	      specify merge tool

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

   revert
       restore files to	their checkout state:

       hg revert [OPTION]... [-r REV] [NAME]...

       Note   To  check	 out  earlier revisions, you should use	hg update REV.
	      To cancel	an uncommitted merge (and lose your changes),  use  hg
	      merge --abort.

       With  no	 revision specified, revert the	specified files	or directories
       to the contents they had	in the parent of the working directory.	  This
       restores	 the  contents of files	to an unmodified state and unschedules
       adds, removes, copies, and renames. If the working  directory  has  two
       parents,	you must explicitly specify a revision.

       Using  the -r/--rev or -d/--date	options, revert	the given files	or di-
       rectories to their states as of a  specific  revision.  Because	revert
       does  not  change  the working directory	parents, this will cause these
       files to	appear modified. This can be helpful to	"back out" some	or all
       of an earlier change. See hg backout for	a related method.

       Modified	files are saved	with a .orig suffix before reverting.  To dis-
       able these backups, use --no-backup. It is possible to store the	backup
       files  in  a custom directory relative to the root of the repository by
       setting the ui.origbackuppath configuration option.

       See hg help dates for a list of formats valid for -d/--date.

       See hg help backout for a way to	 reverse  the  effect  of  an  earlier
       changeset.

       Returns 0 on success.

       Options:

       -a, --all
	      revert all changes when no arguments given

       -d,--date <DATE>
	      tipmost revision matching	date

       -r,--rev	<REV>
	      revert to	the specified revision

       -C, --no-backup
	      do not save backup copies	of files

       -i, --interactive
	      interactively select the changes

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -n, --dry-run
	      do not perform actions, just print output

       [+] marked option can be	specified multiple times

   root
       print the root (top) of the current working directory:

       hg root

       Print the root directory	of the current repository.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       hgpath String. Path to the .hg directory.

       storepath
	      String. Path to the directory holding versioned data.

       Returns 0 on success.

       Options:

       -T,--template <TEMPLATE>
	      display with template

   shelve
       save and	set aside changes from the working directory:

       hg shelve [OPTION]... [FILE]...

       Shelving	takes files that "hg status" reports as	not clean,  saves  the
       modifications  to a bundle (a shelved change), and reverts the files so
       that their state	in the working directory becomes clean.

       To restore these	changes	to the working directory, using	"hg unshelve";
       this will work even if you switch to a different	commit.

       When  no	files are specified, "hg shelve" saves all not-clean files. If
       specific	files or directories are named,	only changes  to  those	 files
       are shelved.

       In  bare	 shelve	(when no files are specified, without interactive, in-
       clude and exclude option), shelving remembers information if the	 work-
       ing  directory  was on newly created branch, in other words working di-
       rectory was on different	branch than its	first parent. In  this	situa-
       tion unshelving restores	branch information to the working directory.

       Each shelved change has a name that makes it easier to find later.  The
       name of a shelved change	defaults to being based	on  the	 active	 book-
       mark,  or if there is no	active bookmark, the current named branch.  To
       specify a different name, use --name.

       To see a	list of	existing shelved changes, use the --list  option.  For
       each  shelved  change,  this will print its name, age, and description;
       use --patch or --stat for more details.

       To delete specific shelved changes, use --delete. To delete all shelved
       changes,	use --cleanup.

       Options:

       -A, --addremove
	      mark new/missing files as	added/removed before shelving

       -u, --unknown
	      store unknown files in the shelve

       --cleanup
	      delete all shelved changes

       --date _DATE_
	      shelve with the specified	commit date

       -d, --delete
	      delete the named shelved change(s)

       -e, --edit
	      invoke editor on commit messages

       -k, --keep
	      shelve, but keep changes in the working directory

       -l, --list
	      list current shelves

       -m,--message <TEXT>
	      use text as shelve message

       -n,--name <NAME>
	      use the given name for the shelved commit

       -p, --patch
	      output  patches  for  changes  (provide the names	of the shelved
	      changes as positional arguments)

       -i, --interactive
	      interactive mode

       --stat output diffstat-style summary of changes (provide	the  names  of
	      the shelved changes as positional	arguments)

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   status
       show changed files in the working directory:

       hg status [OPTION]... [FILE]...

       Show  status of files in	the repository.	If names are given, only files
       that match are shown. Files that	are clean or ignored or	the source  of
       a  copy/move operation, are not listed unless -c/--clean, -i/--ignored,
       -C/--copies or -A/--all are given.  Unless options described with "show
       only ..." are given, the	options	-mardu are used.

       Option  -q/--quiet  hides  untracked (unknown and ignored) files	unless
       explicitly requested with -u/--unknown or -i/--ignored.

       Note   hg status	may appear to disagree with diff if  permissions  have
	      changed  or  a merge has occurred. The standard diff format does
	      not report permission changes and	diff only reports changes rel-
	      ative to one merge parent.

       If  one revision	is given, it is	used as	the base revision.  If two re-
       visions are given, the differences between them are shown. The --change
       option  can  also  be used as a shortcut	to list	the changed files of a
       revision	from its first parent.

       The codes used to show the status of files are:

       M = modified
       A = added
       R = removed
       C = clean
       ! = missing (deleted by non-hg command, but still tracked)
       ? = not tracked
       I = ignored
	 = origin of the previous file (with --copies)

       The -t/--terse option abbreviates the output by showing only the	direc-
       tory  name  if  all  the	 files in it share the same status. The	option
       takes an	argument indicating the	statuses to abbreviate:	'm' for	'modi-
       fied',  'a'  for	'added', 'r' for 'removed', 'd'	for 'deleted', 'u' for
       'unknown', 'i' for 'ignored' and	'c' for	clean.

       It abbreviates only those statuses which	are passed.  Note  that	 clean
       and  ignored  files  are	 not  displayed	 with  '--terse	ic' unless the
       -c/--clean and -i/--ignored options are also used.

       The -v/--verbose	option shows information when the repository is	in  an
       unfinished  merge, shelve, rebase state etc. You	can have this behavior
       turned on by default by enabling	the commands.status.verbose option.

       You can skip displaying some of these states by	setting	 commands.sta-
       tus.skipstates  to  one	or  more  of:  'bisect',  'graft', 'histedit',
       'merge',	'rebase', or 'unshelve'.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       path   String. Repository-absolute path of the file.

       source String.  Repository-absolute  path  of the file originated from.
	      Available	if --copies is specified.

       status String. Character	denoting file's	status.

       Examples:

       o show changes in the working directory relative	to a changeset:

	 hg status --rev 9353

       o show changes in the working directory relative	to the current	direc-
	 tory (see hg help patterns for	more information):

	 hg status re:

       o show all changes including copies in an existing changeset:

	 hg status --copies --change 9353

       o get a NUL separated list of added files, suitable for xargs:

	 hg status -an0

       o show  more  information  about	 the  repository  status, abbreviating
	 added,	removed, modified, deleted, and	untracked paths:

	 hg status -v -t mardu

       Returns 0 on success.

       Options:

       -A, --all
	      show status of all files

       -m, --modified
	      show only	modified files

       -a, --added
	      show only	added files

       -r, --removed
	      show only	removed	files

       -d, --deleted
	      show only	deleted	(but tracked) files

       -c, --clean
	      show only	files without changes

       -u, --unknown
	      show only	unknown	(not tracked) files

       -i, --ignored
	      show only	ignored	files

       -n, --no-status
	      hide status prefix

       -t,--terse <VALUE>
	      show the terse output (EXPERIMENTAL) (default: nothing)

       -C, --copies
	      show source of copied files

       -0, --print0
	      end filenames with NUL, for use with xargs

       --rev _REV[+]_
	      show difference from revision

       --change	_REV_
	      list the changed files of	a revision

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -S, --subrepos
	      recurse into subrepositories

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

	  aliases: st

   summary
       summarize working directory state:

       hg summary [--remote]

       This generates a	brief summary of the working directory state,  includ-
       ing parents, branch, commit status, phase and available updates.

       With  the --remote option, this will check the default paths for	incom-
       ing and outgoing	changes. This can be time-consuming.

       Returns 0 on success.

       Options:

       --remote
	      check for	push and pull

	      aliases: sum

   unshelve
       restore a shelved change	to the working directory:

       hg unshelve [OPTION]... [FILE]... [-n SHELVED]

       This command accepts an optional	name of	a shelved change  to  restore.
       If none is given, the most recent shelved change	is used.

       If  a  shelved change is	applied	successfully, the bundle that contains
       the shelved changes is moved to a backup	location (.hg/shelve-backup).

       Since you can restore a shelved change on top of	an  arbitrary  commit,
       it  is  possible	that unshelving	will result in a conflict between your
       changes and the commits you are unshelving onto.	If  this  occurs,  you
       must resolve the	conflict, then use --continue to complete the unshelve
       operation. (The bundle will not be moved	until  you  successfully  com-
       plete the unshelve.)

       (Alternatively,	you can	use --abort to abandon an unshelve that	causes
       a conflict. This	reverts	the unshelved changes, and leaves  the	bundle
       in place.)

       If  bare	 shelved change	(when no files are specified, without interac-
       tive, include and exclude option) was done on newly created  branch  it
       would restore branch information	to the working directory.

       After a successful unshelve, the	shelved	changes	are stored in a	backup
       directory. Only the N most recent backups are kept. N  defaults	to  10
       but can be overridden using the shelve.maxbackups configuration option.

       Timestamp  in  seconds  is  used	 to decide order of backups. More than
       maxbackups backups are kept, if same timestamp prevents	from  deciding
       exact order of them, for	safety.

       Selected	changes	can be unshelved with --interactive flag.  The working
       directory is updated with the selected changes, and only	the unselected
       changes	remain	shelved.  Note:	The whole shelve is applied to working
       directory first before running interactively. So, this  will  bring  up
       all  the	 conflicts between working directory and the shelve, irrespec-
       tive of which changes will be unshelved.

       Options:

       -a, --abort
	      abort an incomplete unshelve operation

       -c, --continue
	      continue an incomplete unshelve operation

       -i, --interactive
	      use interactive mode (EXPERIMENTAL)

       -k, --keep
	      keep shelve after	unshelving

       -n,--name <NAME>
	      restore shelved change with given	name

       -t,--tool <VALUE>
	      specify merge tool

       --date _DATE_
	      set date for temporary commits (DEPRECATED)

   update
       update working directory	(or switch revisions):

       hg update [-C|-c|-m] [-d	DATE] [[-r] REV]

       Update the repository's working directory to the	 specified  changeset.
       If  no  changeset  is specified,	update to the tip of the current named
       branch and move the active bookmark (see	hg help	bookmarks).

       Update sets the working directory's parent revision  to	the  specified
       changeset (see hg help parents).

       If  the changeset is not	a descendant or	ancestor of the	working	direc-
       tory's parent and there are uncommitted changes,	the update is aborted.
       With the	-c/--check option, the working directory is checked for	uncom-
       mitted changes; if none are found, the working directory	is updated  to
       the specified changeset.

       The -C/--clean, -c/--check, and -m/--merge options control what happens
       if the working directory	contains uncommitted changes.  At most of  one
       of them can be specified.

       1. If  no option	is specified, and if the requested changeset is	an an-
	  cestor or descendant of the working directory's parent,  the	uncom-
	  mitted  changes  are	merged	into  the  requested changeset and the
	  merged result	is left	uncommitted. If	the requested changeset	is not
	  an  ancestor	or  descendant (that is, it is on another branch), the
	  update is aborted and	the uncommitted	changes	are preserved.

       2. With the -m/--merge option, the update is allowed even  if  the  re-
	  quested  changeset  is  not an ancestor or descendant	of the working
	  directory's parent.

       3. With the -c/--check option, the update is aborted and	the  uncommit-
	  ted changes are preserved.

       4. With	the  -C/--clean	 option, uncommitted changes are discarded and
	  the working directory	is updated to the requested changeset.

       To cancel an uncommitted	merge (and lose	your changes),	use  hg	 merge
       --abort.

       Use  null  as  the  changeset  to remove	the working directory (like hg
       clone -U).

       If you want to revert just one file to an older revision, use hg	revert
       [-r REV]	NAME.

       See hg help dates for a list of formats valid for -d/--date.

       Returns 0 on success, 1 if there	are unresolved files.

       Options:

       -C, --clean
	      discard uncommitted changes (no backup)

       -c, --check
	      require clean working directory

       -m, --merge
	      merge uncommitted	changes

       -d,--date <DATE>
	      tipmost revision matching	date

       -r,--rev	<REV>
	      revision

       -t,--tool <TOOL>
	      specify merge tool

	      aliases: up checkout co

   Change import/export
   archive
       create an unversioned archive of	a repository revision:

       hg archive [OPTION]... DEST

       By  default,  the revision used is the parent of	the working directory;
       use -r/--rev to specify a different revision.

       The archive type	is automatically detected based	on file	extension  (to
       override, use -t/--type).

       Examples:

       o create	a zip file containing the 1.0 release:

	 hg archive -r 1.0 project-1.0.zip

       o create	a tarball excluding .hg	files:

	 hg archive project.tar.gz -X ".hg*"

       Valid types are:

       files

	      a	directory full of files	(default)

       tar

	      tar archive, uncompressed

       tbz2

	      tar archive, compressed using bzip2

       tgz

	      tar archive, compressed using gzip

       uzip

	      zip archive, uncompressed

       zip

	      zip archive, compressed using deflate

       The exact name of the destination archive or directory is given using a
       format string; see hg help export for details.

       Each member added to an archive file has	a directory prefix  prepended.
       Use  -p/--prefix	to specify a format string for the prefix. The default
       is the basename of the archive, with suffixes removed.

       Returns 0 on success.

       Options:

       --no-decode
	      do not pass files	through	decoders

       -p,--prefix <PREFIX>
	      directory	prefix for files in archive

       -r,--rev	<REV>
	      revision to distribute

       -t,--type <TYPE>
	      type of distribution to create

       -S, --subrepos
	      recurse into subrepositories

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   bundle
       create a	bundle file:

       hg bundle [-f] [-t BUNDLESPEC] [-a] [-r REV]... [--base REV]... FILE [DEST]

       Generate	a bundle file containing data to  be  transferred  to  another
       repository.

       To  create  a bundle containing all changesets, use -a/--all (or	--base
       null). Otherwise, hg assumes the	destination will have  all  the	 nodes
       you  specify  with  --base  parameters.	Otherwise,  hg will assume the
       repository has all the nodes in destination, or default-push/default if
       no  destination	is  specified, where destination is the	repository you
       provide through DEST option.

       You can change bundle format with the -t/--type	option.	 See  hg  help
       bundlespec for  documentation  on this format. By default, the most ap-
       propriate format	is used	and compression	defaults to bzip2.

       The bundle file can then	be transferred using  conventional  means  and
       applied	to  another repository with the	unbundle or pull command. This
       is useful when direct push and pull are not available or	when exporting
       an entire repository is undesirable.

       Applying	 bundles  preserves  all  changeset contents including permis-
       sions, copy/rename information, and revision history.

       Returns 0 on success, 1 if no changes found.

       Options:

       -f, --force
	      run even when the	destination is unrelated

       -r,--rev	<REV[+]>
	      a	changeset intended to be added to the destination

       -b,--branch <BRANCH[+]>
	      a	specific branch	you would like to bundle

       --base _REV[+]_
	      a	base changeset assumed to be available at the destination

       -a, --all
	      bundle all changesets in the repository

       -t,--type <TYPE>
	      bundle compression type to use (default: bzip2)

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   export
       dump the	header and diffs for one or more changesets:

       hg export [OPTION]... [-o OUTFILESPEC] [-r] [REV]...

       Print the changeset header and diffs for	one or more revisions.	If  no
       revision	is given, the parent of	the working directory is used.

       The  information	shown in the changeset header is: author, date,	branch
       name (if	non-default), changeset	hash, parent(s)	and commit comment.

       Note   hg export	may generate unexpected	diff output for	merge  change-
	      sets,  as	 it will compare the merge changeset against its first
	      parent only.

       Output may be to	a file,	in which case the name of the  file  is	 given
       using a template	string.	See hg help templates. In addition to the com-
       mon template keywords, the following formatting rules are supported:

       %%

	      literal "%" character

       %H

	      changeset	hash (40 hexadecimal digits)

       %N

	      number of	patches	being generated

       %R

	      changeset	revision number

       %b

	      basename of the exporting	repository

       %h

	      short-form changeset hash	(12 hexadecimal	digits)

       %m

	      first line of the	commit message (only alphanumeric characters)

       %n

	      zero-padded sequence number, starting at 1

       %r

	      zero-padded changeset revision number

       \

	      literal "" character

       Without the -a/--text option, export will  avoid	 generating  diffs  of
       files  it  detects as binary. With -a, export will generate a diff any-
       way, probably with undesirable results.

       With -B/--bookmark changesets reachable by the given bookmark  are  se-
       lected.

       Use the -g/--git	option to generate diffs in the	git extended diff for-
       mat. See	hg help	diffs for more information.

       With the	--switch-parent	option,	the diff will be  against  the	second
       parent. It can be useful	to review a merge.

       Template:

       The following keywords are supported in addition	to the common template
       keywords	and functions. See also	hg help	templates.

       diff   String. Diff content.

       parents
	      List of strings. Parent nodes of the changeset.

       Examples:

       o use export and	import to transplant a bugfix to the current branch:

	 hg export -r 9353 | hg	import -

       o export	all the	changesets between two revisions to a file with	rename
	 information:

	 hg export --git -r 123:150 > changes.txt

       o split	outgoing  changes  into	 a  series of patches with descriptive
	 names:

	 hg export -r "outgoing()" -o "%n-%m.patch"

       Returns 0 on success.

       Options:

       -B,--bookmark <BOOKMARK>
	      export changes only reachable by given bookmark

       -o,--output <FORMAT>
	      print output to file with	formatted name

       --switch-parent
	      diff against the second parent

       -r,--rev	<REV[+]>
	      revisions	to export

       -a, --text
	      treat all	files as text

       -g, --git
	      use git extended diff format

       --binary
	      generate binary diffs in git mode	(default)

       --nodates
	      omit dates from diff headers

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

   import
       import an ordered set of	patches:

       hg import [OPTION]... PATCH...

       Import a	list of	patches	and commit them	individually (unless --no-com-
       mit is specified).

       To read a patch from standard input (stdin), use	"-" as the patch name.
       If a URL	is specified, the patch	will be	downloaded from	there.

       Import first applies changes to the working directory (unless  --bypass
       is specified), import will abort	if there are outstanding changes.

       Use  --bypass  to  apply	and commit patches directly to the repository,
       without affecting the working directory.	Without	--exact, patches  will
       be applied on top of the	working	directory parent revision.

       You  can	 import	 a patch straight from a mail message. Even patches as
       attachments work	(to use	the body part, it must have type text/plain or
       text/x-patch).  From  and  Subject headers of email message are used as
       default committer and commit message. All text/plain body parts	before
       first diff are added to the commit message.

       If  the imported	patch was generated by hg export, user and description
       from patch override values from message headers and body. Values	 given
       on command line with -m/--message and -u/--user override	these.

       If  --exact  is specified, import will set the working directory	to the
       parent of each patch before applying it,	and will abort if the  result-
       ing  changeset  has  a different	ID than	the one	recorded in the	patch.
       This will guard against various ways that portable  patch  formats  and
       mail  systems might fail	to transfer Mercurial data or metadata.	See hg
       bundle for lossless transmission.

       Use --partial to	ensure a changeset will	be created from	the patch even
       if  some	 hunks fail to apply. Hunks that fail to apply will be written
       to a <target-file>.rej file. Conflicts can then be resolved by hand be-
       fore  hg	 commit	 --amend is  run to update the created changeset. This
       flag exists to let people import	patches	that partially	apply  without
       losing the associated metadata (author, date, description, ...).

       Note   When  no hunks apply cleanly, hg import --partial	will create an
	      empty changeset, importing only the patch	metadata.

       With -s/--similarity, hg	will attempt to	discover renames and copies in
       the patch in the	same way as hg addremove.

       It  is  possible	to use external	patch programs to perform the patch by
       setting the ui.patch configuration option.  For	the  default  internal
       tool, the fuzz can also be configured via patch.fuzz.  See hg help con-
       fig for more information	about configuration files and how to use these
       options.

       See hg help dates for a list of formats valid for -d/--date.

       Examples:

       o import	a traditional patch from a website and detect renames:

	 hg import -s 80 http://example.com/bugfix.patch

       o import	a changeset from an hgweb server:

	 hg import https://www.mercurial-scm.org/repo/hg/rev/5ca8c111e9aa

       o import	all the	patches	in an Unix-style mbox:

	 hg import incoming-patches.mbox

       o import	patches	from stdin:

	 hg import -

       o attempt  to  exactly restore an exported changeset (not always	possi-
	 ble):

	 hg import --exact proposed-fix.patch

       o use an	external tool to apply a patch which is	too fuzzy for the  de-
	 fault internal	tool.

	    hg import --config ui.patch="patch --merge"	fuzzy.patch

       o change	the default fuzzing from 2 to a	less strict 7

	    hg import --config ui.fuzz=7 fuzz.patch

       Returns 0 on success, 1 on partial success (see --partial).

       Options:

       -p,--strip <NUM>
	      directory	 strip	option for patch. This has the same meaning as
	      the corresponding	patch option (default: 1)

       -b,--base <PATH>
	      base path	(DEPRECATED)

       -e, --edit
	      invoke editor on commit messages

       -f, --force
	      skip check for outstanding uncommitted changes (DEPRECATED)

       --no-commit
	      don't commit, just update	the working directory

       --bypass
	      apply patch without touching the working directory

       --partial
	      commit even if some hunks	fail

       --exact
	      abort if patch would apply lossily

       --prefix	_DIR_
	      apply patch to subdirectory

       --import-branch
	      use any branch information in patch (implied by --exact)

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -s,--similarity <SIMILARITY>
	      guess renamed files by similarity	(0<=s<=100)

	      aliases: patch

   unbundle
       apply one or more bundle	files:

       hg unbundle [-u]	FILE...

       Apply one or more bundle	files generated	by hg bundle.

       Returns 0 on success, 1 if an update has	unresolved files.

       Options:

       -u, --update
	      update to	new branch head	if changesets were unbundled

   Repository maintenance
   manifest
       output the current or given revision of the project manifest:

       hg manifest [-r REV]

       Print a list of version controlled files	for the	given revision.	 If no
       revision	 is  given, the	first parent of	the working directory is used,
       or the null revision if no revision is checked out.

       With -v,	print file permissions,	symlink	 and  executable  bits.	  With
       --debug,	print file revision hashes.

       If  option --all	is specified, the list of all files from all revisions
       is printed. This	includes deleted and renamed files.

       Returns 0 on success.

       Options:

       -r,--rev	<REV>
	      revision to display

       --all  list files from all revisions

       -T,--template <TEMPLATE>
	      display with template

   recover
       roll back an interrupted	transaction:

       hg recover

       Recover from an interrupted commit or pull.

       This command tries to fix the repository	status	after  an  interrupted
       operation. It should only be necessary when Mercurial suggests it.

       Returns 0 if successful,	1 if nothing to	recover	or verify fails.

       Options:

       --verify
	      run hg verify after succesful recover (default: True)

   rollback
       roll back the last transaction (DANGEROUS) (DEPRECATED):

       hg rollback

       Please use hg commit --amend instead of rollback	to correct mistakes in
       the last	commit.

       This command should be used with	care. There is only one	level of roll-
       back,  and there	is no way to undo a rollback. It will also restore the
       dirstate	at the time of	the  last  transaction,	 losing	 any  dirstate
       changes since that time.	This command does not alter the	working	direc-
       tory.

       Transactions are	used to	encapsulate the	effects	of all	commands  that
       create  new  changesets or propagate existing changesets	into a reposi-
       tory.

       For example, the	following commands are transactional,  and  their  ef-
       fects can be rolled back:

       o commit

       o import

       o pull

       o push (with this repository as the destination)

       o unbundle

       To avoid	permanent data loss, rollback will refuse to rollback a	commit
       transaction if it isn't checked out. Use	--force	to override this  pro-
       tection.

       The  rollback  command can be entirely disabled by setting the ui.roll-
       back configuration setting to false. If you're here because you want to
       use  rollback  and it's disabled, you can re-enable the command by set-
       ting ui.rollback	to true.

       This command is not intended  for  use  on  public  repositories.  Once
       changes are visible for pull by other users, rolling a transaction back
       locally is ineffective  (someone	 else  may  already  have  pulled  the
       changes).  Furthermore,	a race is possible with	readers	of the reposi-
       tory; for example an in-progress	pull from the repository may fail if a
       rollback	is performed.

       Returns 0 on success, 1 if no rollback data is available.

       Options:

       -n, --dry-run
	      do not perform actions, just print output

       -f, --force
	      ignore safety measures

   verify
       verify the integrity of the repository:

       hg verify

       Verify the integrity of the current repository.

       This  will  perform  an	extensive check	of the repository's integrity,
       validating the hashes and checksums of each  entry  in  the  changelog,
       manifest,  and  tracked	files,	as  well  as  the  integrity  of their
       crosslinks and indices.

       Please see https://mercurial-scm.org/wiki/RepositoryCorruption for more
       information about recovery from corruption of the repository.

       Returns 0 on success, 1 if errors are encountered.

       Options:

       --full perform more checks (EXPERIMENTAL)

   Help
   config
       show combined config settings from all hgrc files:

       hg config [-u] [NAME]...

       With no arguments, print	names and values of all	config items.

       With  one  argument  of	the form section.name, print just the value of
       that config item.

       With multiple arguments,	print names and	values	of  all	 config	 items
       with matching section names or section.names.

       With  --edit,  start  an	 editor	 on  the  user-level config file. With
       --global, edit the system-wide config  file.  With  --local,  edit  the
       repository-level	config file.

       With --debug, the source	(filename and line number) is printed for each
       config item.

       See hg help config for more information about config files.

       Template:

       The following keywords are supported. See also hg help templates.

       name   String. Config name.

       source String. Filename and line	number where the item is defined.

       value  String. Config value.

       Returns 0 on success, 1 if NAME does not	exist.

       Options:

       -u, --untrusted
	      show untrusted configuration options

       -e, --edit
	      edit user	config

       -l, --local
	      edit repository config

       -g, --global
	      edit global config

       -T,--template <TEMPLATE>
	      display with template

	      aliases: showconfig debugconfig

   help
       show help for a given topic or a	help overview:

       hg help [-eck] [-s PLATFORM] [TOPIC]

       With no arguments, print	a list of commands with	short help messages.

       Given a topic, extension, or command name, print	help for that topic.

       Returns 0 if successful.

       Options:

       -e, --extension
	      show only	help for extensions

       -c, --command
	      show only	help for commands

       -k, --keyword
	      show topics matching keyword

       -s,--system <PLATFORM[+]>
	      show help	for specific platform(s)

       [+] marked option can be	specified multiple times

   version
       output version and copyright information:

       hg version

       Template:

       The following keywords are supported. See also hg help templates.

       extensions
	      List of extensions.

       ver    String. Version number.

       And each	entry of {extensions} provides the following  sub-keywords  in
       addition	to {ver}.

       bundled
	      Boolean. True if included	in the release.

       name   String. Extension	name.

       Options:

       -T,--template <TEMPLATE>
	      display with template

   Uncategorized commands
BUNDLE FILE FORMATS
       Mercurial  supports  generating	standalone  "bundle"  files  that hold
       repository data.	These "bundles"	are typically saved locally  and  used
       later  or exchanged between different repositories, possibly on differ-
       ent machines. Example commands using bundles are	hg bundle and  hg  un-
       bundle.

       Generation  of  bundle  files is	controlled by a	"bundle	specification"
       ("bundlespec") string. This string tells	the bundle generation  process
       how to create the bundle.

       A "bundlespec" string is	composed of the	following elements:

       type   A	string denoting	the bundle format to use.

       compression
	      Denotes the compression engine to	use compressing	the raw	bundle
	      data.

       parameters
	      Arbitrary	key-value parameters to	further	control	bundle genera-
	      tion.

       A "bundlespec" string has the following formats:

       <type> The literal bundle format	string is used.

       <compression>-<type>
	      The compression engine and format	are delimited by a hyphen (-).

       Optional	 parameters  follow  the  <type>.  Parameters  are URI escaped
       key=value pairs.	Each pair is delimited by a semicolon (;).  The	 first
       parameter begins	after a	; immediately following	the <type> value.

   Available Types
       The following bundle <type> strings are available:

       v1     Produces a legacy	"changegroup" version 1	bundle.

	      This  format is compatible with nearly all Mercurial clients be-
	      cause it is the oldest. However, it has some limitations,	 which
	      is why it	is no longer the default for new repositories.

	      v1  bundles can be used with modern repositories using the "gen-
	      eraldelta" storage format. However, it may take longer  to  pro-
	      duce  the	 bundle	 and the resulting bundle may be significantly
	      larger than a v2 bundle.

	      v1 bundles can only use the gzip,	bzip2,	and  none  compression
	      formats.

       v2     Produces a version 2 bundle.

	      Version  2 bundles are an	extensible format that can store addi-
	      tional repository	data (such as bookmarks	 and  phases  informa-
	      tion)  and  they	can  store data	more efficiently, resulting in
	      smaller bundles.

	      Version 2	bundles	can also use modern compression	engines,  such
	      as zstd, making them faster to compress and often	smaller.

   Available Compression Engines
       The following bundle <compression> engines can be used:

       bzip2

	      An algorithm that	produces smaller bundles than gzip.

	      All Mercurial clients should support this	format.

	      This  engine  will  likely produce smaller bundles than gzip but
	      will be significantly slower, both during	compression and	decom-
	      pression.

	      If  available,  the zstd engine can yield	similar	or better com-
	      pression at much higher speeds.

       gzip

	      zlib compression using the DEFLATE algorithm.

	      All Mercurial clients should support this	format.	 The  compres-
	      sion  algorithm strikes a	reasonable balance between compression
	      ratio and	size.

       none

	      No compression is	performed.

	      Use this compression engine to explicitly	disable	compression.

   Examples
       v2

	      Produce a	v2 bundle using	default	 options,  including  compres-
	      sion.

       none-v1

	      Produce a	v1 bundle with no compression.

       zstd-v2

	      Produce  a  v2  bundle  with zstandard compression using default
	      settings.

       zstd-v1

	      This errors because zstd is not supported	for v1 types.

COLORIZING OUTPUTS
       Mercurial colorizes output from several commands.

       For example, the	diff command shows additions in	green and deletions in
       red,  while  the	 status	 command shows modified	files in magenta. Many
       other commands have analogous colors. It	is possible to customize these
       colors.

       To enable color (default) whenever possible use:

       [ui]
       color = yes

       To disable color	use:

       [ui]
       color = no

       See hg help config.ui.color for details.

       The  default  pager  on Windows does not	support	color, so enabling the
       pager will effectively disable color.  See hg  help  config.ui.paginate
       to disable the pager.  Alternately, MSYS	and Cygwin shells provide less
       as a pager, which can be	configured to support ANSI color  mode.	  Win-
       dows 10 natively	supports ANSI color mode.

   Mode
       Mercurial can use various systems to display color. The supported modes
       are ansi, win32,	and terminfo.  See hg  help  config.color for  details
       about how to control the	mode.

   Effects
       Other  effects in addition to color, like bold and underlined text, are
       also available. By default, the terminfo	database is used to  find  the
       terminal	 codes	used  to  change color and effect.  If terminfo	is not
       available, then effects are rendered with the ECMA-48 SGR control func-
       tion (aka ANSI escape codes).

       The available effects in	terminfo mode are 'blink', 'bold', 'dim', 'in-
       verse', 'invisible', 'italic', 'standout', and 'underline'; in  ECMA-48
       mode,  the  options  are	 'bold', 'inverse', 'italic', and 'underline'.
       How each	is rendered depends on the terminal emulator.  Some may	not be
       available for a given terminal type, and	will be	silently ignored.

       If  the terminfo	entry for your terminal	is missing codes for an	effect
       or has the wrong	codes, you can add or override	those  codes  in  your
       configuration:

       [color]
       terminfo.dim = \E[2m

       where 'E' is substituted	with an	escape character.

   Labels
       Text  receives  color effects depending on the labels that it has. Many
       default Mercurial commands emit labelled	text. You can also define your
       own labels in templates using the label function, see hg	help templates
       . A single portion of text may have more	than one label.	In that	 case,
       effects	given  to the last label will override any other effects. This
       includes	the special "none" effect, which nullifies other effects.

       Labels are normally invisible. In order to see these labels  and	 their
       position	in the text, use the global --color=debug option. The same an-
       chor text may be	associated to multiple labels, e.g.

	  [log.changeset changeset.secret|changeset:   22611:6f0a53c8f587]

       The following are the default effects for some default labels.  Default
       effects may be overridden from your configuration file:

       [color]
       status.modified = blue bold underline red_background
       status.added = green bold
       status.removed =	red bold blue_background
       status.deleted =	cyan bold underline
       status.unknown =	magenta	bold underline
       status.ignored =	black bold

       # 'none'	turns off all effects
       status.clean = none
       status.copied = none

       qseries.applied = blue bold underline
       qseries.unapplied = black bold
       qseries.missing = red bold

       diff.diffline = bold
       diff.extended = cyan bold
       diff.file_a = red bold
       diff.file_b = green bold
       diff.hunk = magenta
       diff.deleted = red
       diff.inserted = green
       diff.changed = white
       diff.tab	=
       diff.trailingwhitespace = bold red_background

       # Blank so it inherits the style	of the surrounding label
       changeset.public	=
       changeset.draft =
       changeset.secret	=

       resolve.unresolved = red	bold
       resolve.resolved	= green	bold

       bookmarks.active	= green

       branches.active = none
       branches.closed = black bold
       branches.current	= green
       branches.inactive = none

       tags.normal = green
       tags.local = black bold

       rebase.rebased =	blue
       rebase.remaining	= red bold

       shelve.age = cyan
       shelve.newest = green bold
       shelve.name = blue bold

       histedit.remaining = red	bold

   Custom colors
       Because	there  are only	eight standard colors, Mercurial allows	you to
       define color names for other color slots	which might be	available  for
       your terminal type, assuming terminfo mode.  For	instance:

       color.brightblue	= 12
       color.pink = 207
       color.orange = 202

       to  set	'brightblue'  to  color	slot 12	(useful	for 16 color terminals
       that have brighter colors defined in the	upper eight) and,  'pink'  and
       'orange'	 to colors in 256-color	xterm's	default	color cube.  These de-
       fined colors may	then be	used as	any of the pre-defined eight,  includ-
       ing appending '_background' to set the background to that color.

DATE FORMATS
       Some commands allow the user to specify a date, e.g.:

       o backout, commit, import, tag: Specify the commit date.

       o log, revert, update: Select revision(s) by date.

       Many date formats are valid. Here are some examples:

       o Wed Dec 6 13:18:29 2006 (local	timezone assumed)

       o Dec 6 13:18 -0600 (year assumed, time offset provided)

       o Dec 6 13:18 UTC (UTC and GMT are aliases for +0000)

       o Dec 6 (midnight)

       o 13:18 (today assumed)

       o 3:39 (3:39AM assumed)

       o 3:39pm	(15:39)

       o 2006-12-06 13:18:29 (ISO 8601 format)

       o 2006-12-6 13:18

       o 2006-12-6

       o 12-6

       o 12/6

       o 12/6/6	(Dec 6 2006)

       o today (midnight)

       o yesterday (midnight)

       o now - right now

       Lastly, there is	Mercurial's internal format:

       o 1165411109 0 (Wed Dec 6 13:18:29 2006 UTC)

       This  is	the internal representation format for dates. The first	number
       is the number of	seconds	since the epoch	(1970-01-01  00:00  UTC).  The
       second  is  the	offset	of  the	local timezone,	in seconds west	of UTC
       (negative if the	timezone is east of UTC).

       The log command also accepts date ranges:

       o <DATE - at or before a	given date/time

       o >DATE - on or after a given date/time

       o DATE to DATE -	a date range, inclusive

       o -DAYS - within	a given	number of days of today

DEPRECATED FEATURES
       Mercurial evolves over time, some features, options,  commands  may  be
       replaced	 by  better and	more secure alternatives. This topic will help
       you migrating your existing usage and/or	configuration  to  newer  fea-
       tures.

   Commands
       The following commands are still	available but their use	are not	recom-
       mended:

       locate

       This command has	been replaced by hg files.

       parents

       This command can	be replaced by hg summary or hg	log  with  appropriate
       revsets.	See hg help revsets for	more information.

       tip

       The recommended alternative is hg heads.

   Options
       web.allowpull

	      Renamed to allow-pull.

       web.allow_push

	      Renamed to allow-push.

DIFF FORMATS
       Mercurial's  default format for showing changes between two versions of
       a file is compatible with the unified format of GNU diff, which can  be
       used by GNU patch and many other	standard tools.

       While this standard format is often enough, it does not encode the fol-
       lowing information:

       o executable status and other permission	bits

       o copy or rename	information

       o changes in binary files

       o creation or deletion of empty files

       Mercurial also supports the extended diff format	from the git VCS which
       addresses these limitations. The	git diff format	is not produced	by de-
       fault because a few widespread tools still do not understand this  for-
       mat.

       This means that when generating diffs from a Mercurial repository (e.g.
       with hg export),	you should be careful about things  like  file	copies
       and  renames  or	 other things mentioned	above, because when applying a
       standard	diff to	a different  repository,  this	extra  information  is
       lost.  Mercurial's internal operations (like push and pull) are not af-
       fected by this, because they use	an internal binary format for communi-
       cating changes.

       To  make	 Mercurial produce the git extended diff format, use the --git
       option available	for many commands, or set 'git = True' in  the	[diff]
       section	of your	configuration file. You	do not need to set this	option
       when importing diffs in this format or using them in the	mq extension.

ENVIRONMENT VARIABLES
       HG     Path to the 'hg' executable, automatically passed	 when  running
	      hooks,  extensions or external tools. If unset or	empty, this is
	      the hg executable's name if it's frozen, or an executable	 named
	      'hg'  (with %PATHEXT% [defaulting	to COM/EXE/BAT/CMD] extensions
	      on Windows) is searched.

       HGEDITOR
	      This is the name of the editor to	run when committing. See  EDI-
	      TOR.

	      (deprecated, see hg help config.ui.editor)

       HGENCODING
	      This overrides the default locale	setting	detected by Mercurial.
	      This setting  is	used  to  convert  data	 including  usernames,
	      changeset	 descriptions,	tag  names, and	branches. This setting
	      can be overridden	with the --encoding command-line option.

       HGENCODINGMODE
	      This sets	Mercurial's behavior for handling  unknown  characters
	      while  transcoding  user	input.	The default is "strict", which
	      causes Mercurial to abort	if it can't  map  a  character.	 Other
	      settings	include	 "replace", which replaces unknown characters,
	      and "ignore", which drops	them. This setting can	be  overridden
	      with the --encodingmode command-line option.

       HGENCODINGAMBIGUOUS
	      This sets	Mercurial's behavior for handling characters with "am-
	      biguous" widths like accented Latin characters with  East	 Asian
	      fonts.  By  default,  Mercurial assumes ambiguous	characters are
	      narrow, set this variable	to "wide"  if  such  characters	 cause
	      formatting problems.

       HGMERGE
	      An  executable to	use for	resolving merge	conflicts. The program
	      will be executed with three arguments: local file, remote	 file,
	      ancestor file.

	      (deprecated, see hg help config.ui.merge)

       HGRCPATH
	      A	 list  of  files  or  directories  to search for configuration
	      files. Item separator is ":" on Unix, ";"	on Windows.  If	 HGRC-
	      PATH is not set, platform	default	search path is used. If	empty,
	      only the .hg/hgrc	from the current repository is read.

	      For each element in HGRCPATH:

	      o	if it's	a directory, all files ending with .rc are added

	      o	otherwise, the file itself will	be added

       HGPLAIN
	      When set,	this disables any configuration	 settings  that	 might
	      change  Mercurial's  default output. This	includes encoding, de-
	      faults, verbose mode, debug mode,	quiet  mode,  tracebacks,  and
	      localization.  This  can be useful when scripting	against	Mercu-
	      rial in the face of existing user	configuration.

	      In addition to the features disabled by HGPLAIN=,	the  following
	      values can be specified to adjust	behavior:

	      +strictflags

		     Restrict parsing of command line flags.

	      Equivalent  options  set	via  command line flags	or environment
	      variables	are not	overridden.

	      See hg help scripting for	details.

       HGPLAINEXCEPT
	      This is a	comma-separated	list of	features to preserve when  HG-
	      PLAIN is enabled.	Currently the following	values are supported:

	      alias

		     Don't remove aliases.

	      color

		     Don't disable colored output.

	      i18n

		     Preserve internationalization.

	      revsetalias

		     Don't remove revset aliases.

	      templatealias

		     Don't remove template aliases.

	      progress

		     Don't hide	progress output.

	      Setting  HGPLAINEXCEPT  to  anything (even an empty string) will
	      enable plain mode.

       HGUSER This is the string used as the author of a commit. If  not  set,
	      available	values will be considered in this order:

	      o	HGUSER (deprecated)

	      o	configuration files from the HGRCPATH

	      o	EMAIL

	      o	interactive prompt

	      o	LOGNAME	(with @hostname	appended)

	      (deprecated, see hg help config.ui.username)

       EMAIL  May be used as the author	of a commit; see HGUSER.

       LOGNAME
	      May be used as the author	of a commit; see HGUSER.

       VISUAL This  is the name	of the editor to use when committing. See EDI-
	      TOR.

       EDITOR Sometimes	Mercurial needs	to open	a text file in an editor for a
	      user  to	modify,	 for example when writing commit messages. The
	      editor it	uses is	determined by looking at the environment vari-
	      ables  HGEDITOR,	VISUAL	and  EDITOR,  in that order. The first
	      non-empty	one is chosen. If all of them are  empty,  the	editor
	      defaults to 'vi'.

       PYTHONPATH
	      This  is used by Python to find imported modules and may need to
	      be set appropriately if this Mercurial  is  not  installed  sys-
	      tem-wide.

USING ADDITIONAL FEATURES
       Mercurial has the ability to add	new features through the use of	exten-
       sions. Extensions may add new commands, add options  to	existing  com-
       mands, change the default behavior of commands, or implement hooks.

       To  enable the "foo" extension, either shipped with Mercurial or	in the
       Python search path, create an entry for it in your configuration	 file,
       like this:

       [extensions]
       foo =

       You may also specify the	full path to an	extension:

       [extensions]
       myfeature = ~/.hgext/myfeature.py

       See hg help config for more information on configuration	files.

       Extensions are not loaded by default for	a variety of reasons: they can
       increase	startup	overhead; they may be meant for	advanced  usage	 only;
       they  may  provide potentially dangerous	abilities (such	as letting you
       destroy or modify history); they	might not be ready for prime time;  or
       they  may  alter	some usual behaviors of	stock Mercurial. It is thus up
       to the user to activate extensions as needed.

       To explicitly disable an	extension enabled in a configuration  file  of
       broader scope, prepend its path with !:

       [extensions]
       # disabling extension bar residing in /path/to/extension/bar.py
       bar = !/path/to/extension/bar.py
       # ditto,	but no path was	supplied for extension baz
       baz = !

       disabled	extensions:

	  acl	 hooks for controlling repository access

	  blackbox
		 log repository	events to a blackbox for debugging

	  bugzilla
		 hooks for integrating with the	Bugzilla bug tracker

	  censor erase file content at a given revision

	  churn	 command to display statistics about repository	history

	  clonebundles
		 advertise pre-generated bundles to seed clones

	  closehead
		 close arbitrary heads without checking	them out first

	  convert
		 import	revisions from foreign VCS repositories	into Mercurial

	  eol	 automatically manage newlines in repository files

	  extdiff
		 command to allow external programs to compare revisions

	  factotum
		 http authentication with factotum

	  githelp
		 try mapping git commands to Mercurial commands

	  gpg	 commands to sign and verify changesets

	  hgk	 browse	the repository in a graphical way

	  highlight
		 syntax	highlighting for hgweb (requires Pygments)

	  histedit
		 interactive history editing

	  keyword
		 expand	keywords in tracked files

	  largefiles
		 track large binary files

	  mq	 manage	a stack	of patches

	  notify hooks for sending email push notifications

	  patchbomb
		 command to send changesets as (a series of) patch emails

	  purge	 command to delete untracked files from	the working directory

	  rebase command to move sets of revisions to a	different ancestor

	  relink recreates hardlinks between repository	clones

	  schemes
		 extend	schemes	with shortcuts to repository swarms

	  share	 share a common	history	between	several	working	directories

	  strip	 strip changesets and their descendants	from history

	  transplant
		 command to transplant changesets from another branch

	  win32mbcs
		 allow the use of MBCS paths with problematic encodings

	  zeroconf
		 discover and advertise	repositories on	the local network

SPECIFYING FILE	SETS
       Mercurial supports a functional language	for selecting a	set of files.

       Like  other  file patterns, this	pattern	type is	indicated by a prefix,
       'set:'. The language supports a number of predicates which  are	joined
       by infix	operators. Parenthesis can be used for grouping.

       Identifiers such	as filenames or	patterns must be quoted	with single or
       double	quotes	  if	they	contain	   characters	 outside    of
       [.*{}[]?/\_a-zA-Z0-9\x80-\xff]  or  if they match one of	the predefined
       predicates. This	generally applies to file patterns  other  than	 globs
       and  arguments  for  predicates.	 Pattern prefixes such as path:	may be
       specified without quoting.

       Special characters can be used in quoted	identifiers by escaping	 them,
       e.g., \n	is interpreted as a newline. To	prevent	them from being	inter-
       preted, strings can be prefixed with r, e.g. r'...'.

       See also	hg help	patterns.

   Operators
       There is	a single prefix	operator:

       not x

	      Files not	in x. Short form is ! x.

       These are the supported infix operators:

       x and y

	      The intersection of files	in x and y. Short form is x & y.

       x or y

	      The union	of files in x and y. There are two  alternative	 short
	      forms: x | y and x + y.

       x - y

	      Files in x but not in y.

   Predicates
       The following predicates	are supported:

       added()

	      File that	is added according to hg status.

       binary()

	      File that	appears	to be binary (contains NUL bytes).

       clean()

	      File that	is clean according to hg status.

       copied()

	      File that	is recorded as being copied.

       deleted()

	      Alias for	missing().

       encoding(name)

	      File can be successfully decoded with the	given character	encod-
	      ing. May not be useful for encodings other than ASCII and	UTF-8.

       eol(style)

	      File contains newlines of	the given style	(dos, unix, mac).  Bi-
	      nary  files  are	excluded,  files with mixed line endings match
	      multiple styles.

       exec()

	      File that	is marked as executable.

       grep(regex)

	      File contains the	given regular expression.

       hgignore()

	      File that	matches	the active .hgignore pattern.

       ignored()

	      File that	is ignored according to	hg status.

       missing()

	      File that	is missing according to	hg status.

       modified()

	      File that	is modified according to hg status.

       portable()

	      File that	has a portable name. (This doesn't  include  filenames
	      with case	collisions.)

       removed()

	      File that	is removed according to	hg status.

       resolved()

	      File that	is marked resolved according to	hg resolve -l.

       revs(revs, pattern)

	      Evaluate	set  in	 the  specified	revisions. If the revset match
	      multiple revs, this will return file matching pattern in any  of
	      the revision.

       size(expression)

	      File size	matches	the given expression. Examples:

	      o	size('1k') - files from	1024 to	2047 bytes

	      o	size('<	20k') -	files less than	20480 bytes

	      o	size('>= .5MB')	- files	at least 524288	bytes

	      o	size('4k - 1MB') - files from 4096 bytes to 1048576 bytes

       status(base, rev, pattern)

	      Evaluate predicate using status change between base and rev. Ex-
	      amples:

	      o	status(3, 7, added()) -	matches	files added from "3" to	"7"

       subrepo([pattern])

	      Subrepositories whose paths match	the given pattern.

       symlink()

	      File that	is marked as a symlink.

       tracked()

	      File that	is under Mercurial control.

       unknown()

	      File that	is unknown according to	hg status.

       unresolved()

	      File that	is marked unresolved according to hg resolve -l.

   Examples
       Some sample queries:

       o Show status of	files that appear to be	binary in the  working	direc-
	 tory:

	 hg status -A "set:binary()"

       o Forget	files that are in .hgignore but	are already tracked:

	 hg forget "set:hgignore() and not ignored()"

       o Find text files that contain a	string:

	 hg files "set:grep(magic) and not binary()"

       o Find C	files in a non-standard	encoding:

	 hg files "set:**.c and	not encoding('UTF-8')"

       o Revert	copies of large	binary files:

	 hg revert "set:copied() and binary() and size('>1M')"

       o Revert	files that were	added to the working directory:

	 hg revert "set:revs('wdir()', added())"

       o Remove	files listed in	foo.lst	that contain the letter	a or b:

	 hg remove "set: listfile:foo.lst and (**a* or **b*)"

COMMAND-LINE FLAGS
       Most Mercurial commands accept various flags.

   Flag	names
       Flags  for  each	command	are listed in hg help for that command.	 Addi-
       tionally, some flags, such as --repository, are global and can be  used
       with  any  command - those are seen in hg help -v, and can be specified
       before or after the command.

       Every flag has at least a long name, such as --repository.  Some	 flags
       may also	have a short one-letter	name, such as the equivalent -R. Using
       the short or long name is equivalent and	has the	same effect.

       Flags that have a short name can	also be	bundled	 together  -  for  in-
       stance, to specify both --edit (short -e) and --interactive (short -i),
       one could use:

       hg commit -ei

       If any of the bundled flags takes a value (i.e. is not a	 boolean),  it
       must be last, followed by the value:

       hg commit -im 'Message'

   Flag	types
       Mercurial  command-line	flags  can  be	strings, numbers, booleans, or
       lists of	strings.

   Specifying flag values
       The following syntaxes are allowed, assuming  a	flag  'flagname'  with
       short name 'f':

       --flagname=foo
       --flagname foo
       -f foo
       -ffoo

       This  syntax  applies  to  all  non-boolean  flags (strings, numbers or
       lists).

   Specifying boolean flags
       Boolean flags do	not take a value parameter. To specify a boolean,  use
       the  flag  name to set it to true, or the same name prefixed with 'no-'
       to set it to false:

       hg commit --interactive
       hg commit --no-interactive

   Specifying list flags
       List flags take multiple	values.	To specify them, pass the flag	multi-
       ple times:

       hg files	--include mercurial --include tests

   Setting flag	defaults
       In  order to set	a default value	for a flag in an hgrc file, it is rec-
       ommended	to use aliases:

       [alias]
       commit =	commit --interactive

       For more	information on hgrc files, see hg help config.

   Overriding flags on the command line
       If the same non-list flag is specified multiple times  on  the  command
       line, the latest	specification is used:

       hg commit -m "Ignored value" -m "Used value"

       This includes the use of	aliases	- e.g.,	if one has:

       [alias]
       committemp = commit -m "Ignored value"

       then the	following command will override	that -m:

       hg committemp -m	"Used value"

   Overriding flag defaults
       Every  flag has a default value,	and you	may also set your own defaults
       in hgrc as described above.  Except for list  flags,  defaults  can  be
       overridden  on  the  command line simply	by specifying the flag in that
       location.

   Hidden flags
       Some flags are not shown	in a command's help by default - specifically,
       those  that  are	 deemed	to be experimental, deprecated or advanced. To
       show all	flags, add the --verbose flag for the help command:

       hg help --verbose commit

GLOSSARY
       Ancestor
	      Any changeset that can be	reached	by an unbroken chain of	parent
	      changesets from a	given changeset. More precisely, the ancestors
	      of a changeset can be defined by two properties: a parent	 of  a
	      changeset	 is an ancestor, and a parent of an ancestor is	an an-
	      cestor. See also:	'Descendant'.

       Bookmark
	      Bookmarks	are pointers to	certain	commits	that move when commit-
	      ting.  They  are	similar	 to tags in that it is possible	to use
	      bookmark names in	all places where Mercurial expects a changeset
	      ID, e.g.,	with hg	update.	Unlike tags, bookmarks move along when
	      you make a commit.

	      Bookmarks	can be renamed,	copied and deleted. Bookmarks are  lo-
	      cal, unless they are explicitly pushed or	pulled between reposi-
	      tories.  Pushing and pulling bookmarks allow you to  collaborate
	      with others on a branch without creating a named branch.

       Branch (Noun)  A	 child	changeset  that	has been created from a	parent
	      that is not a head. These	are known as topological branches, see
	      'Branch,	topological'. If a topological branch is named,	it be-
	      comes a named branch. If a topological branch is not  named,  it
	      becomes	an  anonymous  branch.	See  'Branch,  anonymous'  and
	      'Branch, named'.

	      Branches may be created when changes are pulled from  or	pushed
	      to  a remote repository, since new heads may be created by these
	      operations. Note that the	term branch can	also  be  used	infor-
	      mally  to	describe a development process in which	certain	devel-
	      opment is	done independently of other development. This is some-
	      times  done  explicitly  with a named branch, but	it can also be
	      done locally, using bookmarks or clones and anonymous branches.

	      Example: "The experimental branch."

	      (Verb) The action	of creating a child changeset which results in
	      its parent having	more than one child.

	      Example: "I'm going to branch at X."

       Branch, anonymous
	      Every  time  a new child changeset is created from a parent that
	      is not a head and	the name of the	branch is not changed,	a  new
	      anonymous	branch is created.

       Branch, closed
	      A	named branch whose branch heads	have all been closed.

       Branch, default
	      The  branch  assigned to a changeset when	no name	has previously
	      been assigned.

       Branch head
	      See 'Head, branch'.

       Branch, inactive
	      If a named branch	has no topological heads, it is	considered  to
	      be  inactive.  As	 an example, a feature branch becomes inactive
	      when it is merged	into the default branch. The hg	 branches com-
	      mand shows inactive branches by default, though they can be hid-
	      den with hg branches --active.

	      NOTE: this concept is deprecated because	it  is	too  implicit.
	      Branches	should	now  be	 explicitly  closed  using  hg	commit
	      --close-branch when they are no longer needed.

       Branch, named
	      A	collection of changesets which have the	same branch  name.  By
	      default, children	of a changeset in a named branch belong	to the
	      same named branch. A child can be	explicitly assigned to a  dif-
	      ferent  branch. See hg help branch, hg help branches and hg com-
	      mit --close-branch for more information on managing branches.

	      Named branches can be thought of as a kind of namespace,	divid-
	      ing  the	collection  of changesets that comprise	the repository
	      into a collection	of disjoint subsets. A	named  branch  is  not
	      necessarily  a topological branch. If a new named	branch is cre-
	      ated from	the head of  another  named  branch,  or  the  default
	      branch,  but  no	further	 changesets are	added to that previous
	      branch, then that	previous branch	will be	a branch in name only.

       Branch tip
	      See 'Tip,	branch'.

       Branch, topological
	      Every time a new child changeset is created from a  parent  that
	      is  not  a head, a new topological branch	is created. If a topo-
	      logical branch is	named, it becomes a named branch. If  a	 topo-
	      logical  branch  is not named, it	becomes	an anonymous branch of
	      the current, possibly default, branch.

       Changelog
	      A	record of the changesets in the	order in which they were added
	      to  the  repository. This	includes details such as changeset id,
	      author, commit message, date, and	list of	changed	files.

       Changeset
	      A	snapshot of the	state of  the  repository  used	 to  record  a
	      change.

       Changeset, child
	      The  converse of parent changeset: if P is a parent of C,	then C
	      is a child of P. There is	no limit to  the  number  of  children
	      that a changeset may have.

       Changeset id
	      A	 SHA-1	hash  that  uniquely identifies	a changeset. It	may be
	      represented as either a "long" 40	hexadecimal digit string, or a
	      "short" 12 hexadecimal digit string.

       Changeset, merge
	      A	 changeset  with two parents. This occurs when a merge is com-
	      mitted.

       Changeset, parent
	      A	revision upon which a child changeset is based.	 Specifically,
	      a	 parent	 changeset  of a changeset C is	a changeset whose node
	      immediately precedes C in	the DAG. Changesets have at  most  two
	      parents.

       Checkout
	      (Noun)  The  working directory being updated to a	specific revi-
	      sion. This use should probably be	 avoided  where	 possible,  as
	      changeset	 is  much  more	appropriate than checkout in this con-
	      text.

	      Example: "I'm using checkout X."

	      (Verb) Updating the working directory to a  specific  changeset.
	      See hg help update.

	      Example: "I'm going to check out changeset X."

       Child changeset
	      See 'Changeset, child'.

       Close changeset
	      See 'Head, closed	branch'.

       Closed branch
	      See 'Branch, closed'.

       Clone  (Noun)  An  entire  or partial copy of a repository. The partial
	      clone must be in the form	of a revision and its ancestors.

	      Example: "Is your	clone up to date?"

	      (Verb) The process of creating a clone, using hg clone.

	      Example: "I'm going to clone the repository."

       Closed branch head
	      See 'Head, closed	branch'.

       Commit (Noun) A synonym for changeset.

	      Example: "Is the bug fixed in your recent	commit?"

	      (Verb) The act of	recording changes to a repository. When	 files
	      are  committed  in a working directory, Mercurial	finds the dif-
	      ferences between the committed files and their parent changeset,
	      creating a new changeset in the repository.

	      Example: "You should commit those	changes	now."

       Cset   A	common abbreviation of the term	changeset.

       DAG    The  repository  of  changesets of a distributed version control
	      system (DVCS) can	be  described  as  a  directed	acyclic	 graph
	      (DAG),  consisting of nodes and edges, where nodes correspond to
	      changesets and edges imply a  parent  ->	child  relation.  This
	      graph  can  be  visualized  by  graphical	 tools	such as	hg log
	      --graph. In Mercurial, the DAG is	limited	by the requirement for
	      children to have at most two parents.

       Deprecated
	      Feature  removed	from  documentation, but not scheduled for re-
	      moval.

       Default branch
	      See 'Branch, default'.

       Descendant
	      Any changeset that can be	reached	by a chain of child changesets
	      from  a  given  changeset.  More precisely, the descendants of a
	      changeset	can be defined by  two	properties:  the  child	 of  a
	      changeset	 is  a	descendant, and	the child of a descendant is a
	      descendant. See also: 'Ancestor'.

       Diff   (Noun) The difference between the	 contents  and	attributes  of
	      files  in	 two changesets	or a changeset and the current working
	      directory. The difference	is usually represented in  a  standard
	      form  called  a "diff" or	"patch". The "git diff"	format is used
	      when the changes include copies, renames,	or changes to file at-
	      tributes,	 none  of  which can be	represented/handled by classic
	      "diff" and "patch".

	      Example: "Did you	see my correction in the diff?"

	      (Verb) Diffing two changesets is the action of creating  a  diff
	      or patch.

	      Example:	"If  you  diff	with  changeset	X, you will see	what I
	      mean."

       Directory, working
	      The working directory represents the state of the	files  tracked
	      by  Mercurial,  that  will  be  recorded in the next commit. The
	      working directory	initially corresponds to the  snapshot	at  an
	      existing	changeset,  known  as the parent of the	working	direc-
	      tory. See	'Parent, working directory'. The state may be modified
	      by  changes  to the files	introduced manually or by a merge. The
	      repository metadata exists in the	.hg directory inside the work-
	      ing directory.

       Draft  Changesets in the	draft phase have not been shared with publish-
	      ing repositories and may thus be safely changed by history-modi-
	      fying extensions.	See hg help phases.

       Experimental
	      Feature that may change or be removed at a later date.

       Graph  See DAG and hg log --graph.

       Head   The  term	'head' may be used to refer to both a branch head or a
	      repository head, depending on the	context.  See  'Head,  branch'
	      and 'Head, repository' for specific definitions.

	      Heads  are  where	 development generally takes place and are the
	      usual targets for	update and merge operations.

       Head, branch
	      A	changeset with no descendants on the same named	branch.

       Head, closed branch
	      A	changeset that marks a head  as	 no  longer  interesting.  The
	      closed head is no	longer listed by hg heads. A branch is consid-
	      ered closed when all its heads are closed	 and  consequently  is
	      not listed by hg branches.

	      Closed heads can be re-opened by committing new changeset	as the
	      child of the changeset that marks	a head as closed.

       Head, repository
	      A	topological head which has not been closed.

       Head, topological
	      A	changeset with no children in the repository.

       History,	immutable
	      Once committed, changesets cannot	be altered.  Extensions	 which
	      appear to	change history actually	create new changesets that re-
	      place existing ones, and then destroy the	old changesets.	 Doing
	      so  in  public  repositories  can	result in old changesets being
	      reintroduced to the repository.

       History,	rewriting
	      The changesets in	a repository are  immutable.  However,	exten-
	      sions  to	Mercurial can be used to alter the repository, usually
	      in such a	way as to preserve changeset contents.

       Immutable history
	      See 'History, immutable'.

       Merge changeset
	      See 'Changeset, merge'.

       Manifest
	      Each changeset has a manifest, which is the list of  files  that
	      are tracked by the changeset.

       Merge  Used  to bring together divergent	branches of work. When you up-
	      date to a	changeset and then merge another changeset, you	 bring
	      the history of the latter	changeset into your working directory.
	      Once conflicts are resolved (and marked),	this merge may be com-
	      mitted  as  a merge changeset, bringing two branches together in
	      the DAG.

       Named branch
	      See 'Branch, named'.

       Null changeset
	      The empty	changeset. It is the parent state of newly-initialized
	      repositories  and	 repositories with no checked out revision. It
	      is thus the parent of root changesets and	the effective ancestor
	      when merging unrelated changesets. Can be	specified by the alias
	      'null' or	by the changeset ID '000000000000'.

       Parent See 'Changeset, parent'.

       Parent changeset
	      See 'Changeset, parent'.

       Parent, working directory
	      The working directory parent reflects a virtual  revision	 which
	      is  the child of the changeset (or two changesets	with an	uncom-
	      mitted merge) shown by hg	parents. This is changed with  hg  up-
	      date.  Other commands to see the working directory parent	are hg
	      summary and hg id. Can be	specified by the alias ".".

       Patch  (Noun) The product of a diff operation.

	      Example: "I've sent you my patch."

	      (Verb) The process of  using  a  patch  file  to	transform  one
	      changeset	into another.

	      Example: "You will need to patch that revision."

       Phase  A	 per-changeset	state  tracking	 how the changeset has been or
	      should be	shared.	See hg help phases.

       Public Changesets in the	public phase have been shared with  publishing
	      repositories and are therefore considered	immutable. See hg help
	      phases.

       Pull   An operation in which changesets in a  remote  repository	 which
	      are  not	in  the	 local	repository  are	brought	into the local
	      repository. Note that this operation without  special  arguments
	      only updates the repository, it does not update the files	in the
	      working directory. See hg	help pull.

       Push   An operation in which changesets in a local repository which are
	      not  in  a  remote repository are	sent to	the remote repository.
	      Note that	this operation only adds changesets  which  have  been
	      committed	 locally to the	remote repository. Uncommitted changes
	      are not sent. See	hg help	push.

       Repository
	      The metadata describing all recorded states of a	collection  of
	      files.  Each  recorded  state  is	 represented by	a changeset. A
	      repository is usually (but not always) found in the  .hg	subdi-
	      rectory of a working directory. Any recorded state can be	recre-
	      ated by "updating" a working directory to	a specific changeset.

       Repository head
	      See 'Head, repository'.

       Revision
	      A	state of the repository	at some	point in time.	Earlier	 revi-
	      sions  can be updated to by using	hg update.  See	also 'Revision
	      number'; See also	'Changeset'.

       Revision	number
	      This integer uniquely  identifies	 a  changeset  in  a  specific
	      repository.  It  represents  the	order in which changesets were
	      added to a repository, starting with  revision  number  0.  Note
	      that  the	 revision  number  may be different in each clone of a
	      repository. To identify changesets  uniquely  between  different
	      clones, see 'Changeset id'.

       Revlog History  storage	mechanism  used	 by Mercurial. It is a form of
	      delta encoding, with occasional full revision of	data  followed
	      by  delta	 of  each successive revision. It includes data	and an
	      index pointing to	the data.

       Rewriting history
	      See 'History, rewriting'.

       Root   A	changeset that has only	the null changeset as its parent. Most
	      repositories have	only a single root changeset.

       Secret Changesets in the	secret phase may not be	shared via push, pull,
	      or clone.	See hg help phases.

       Tag    An alternative name given	to a changeset.	Tags can  be  used  in
	      all places where Mercurial expects a changeset ID, e.g., with hg
	      update. The creation of a	tag is stored in the history and  will
	      thus automatically be shared with	other using push and pull.

       Tip    The  changeset  with  the	 highest  revision  number.  It	is the
	      changeset	most recently added in a repository.

       Tip, branch
	      The head of a given branch with  the  highest  revision  number.
	      When  a  branch name is used as a	revision identifier, it	refers
	      to the branch tip. See also 'Branch, head'.  Note	 that  because
	      revision	numbers	 may  be  different  in	 different  repository
	      clones, the branch tip may  be  different	 in  different	cloned
	      repositories.

       Update (Noun) Another synonym of	changeset.

	      Example: "I've pushed an update."

	      (Verb)  This term	is usually used	to describe updating the state
	      of the working directory to that of a specific changeset.	See hg
	      help update.

	      Example: "You should update."

       Working directory
	      See 'Directory, working'.

       Working directory parent
	      See 'Parent, working directory'.

SYNTAX FOR MERCURIAL IGNORE FILES
   Synopsis
       The Mercurial system uses a file	called .hgignore in the	root directory
       of a repository to control its behavior when it searches	for files that
       it is not currently tracking.

   Description
       The  working  directory	of  a  Mercurial repository will often contain
       files that should not be	tracked	by  Mercurial.	These  include	backup
       files  created  by  editors  and	 build	products created by compilers.
       These files can be ignored by listing them in a .hgignore file  in  the
       root of the working directory. The .hgignore file must be created manu-
       ally. It	is typically put under version control,	so that	 the  settings
       will propagate to other repositories with push and pull.

       An  untracked  file  is	ignored	if its path relative to	the repository
       root directory, or any prefix path of that path,	is matched against any
       pattern in .hgignore.

       For  example,  say we have an untracked file, file.c, at	a/b/file.c in-
       side our	repository. Mercurial will ignore file.c  if  any  pattern  in
       .hgignore matches a/b/file.c, a/b or a.

       In  addition,  a	 Mercurial  configuration  file	can reference a	set of
       per-user	or global ignore files.	See the	ignore	configuration  key  on
       the  [ui]  section  of  hg  help	config for details of how to configure
       these files.

       To control Mercurial's handling of files	that it	manages, many commands
       support	the  -I	and -X options;	see hg help <command> and hg help pat-
       terns for details.

       Files that are already tracked are not affected by .hgignore,  even  if
       they  appear  in	.hgignore. An untracked	file X can be explicitly added
       with hg add X, even if X	would be excluded by a pattern in .hgignore.

   Syntax
       An ignore file is a plain text file consisting of a list	 of  patterns,
       with  one pattern per line. Empty lines are skipped. The	# character is
       treated as a comment character, and the \ character is  treated	as  an
       escape character.

       Mercurial supports several pattern syntaxes. The	default	syntax used is
       Python/Perl-style regular expressions.

       To change the syntax used, use a	line of	the following form:

       syntax: NAME

       where NAME is one of the	following:

       regexp

	      Regular expression, Python/Perl syntax.

       glob

	      Shell-style glob.

       rootglob

	      A	variant	of glob	that is	rooted (see below).

       The chosen syntax stays in effect when parsing all patterns  that  fol-
       low, until another syntax is selected.

       Neither	glob  nor regexp patterns are rooted. A	glob-syntax pattern of
       the form	*.c will match a file ending in	.c in  any  directory,	and  a
       regexp pattern of the form \.c$ will do the same. To root a regexp pat-
       tern, start it with ^. To get the same  effect  with  glob-syntax,  you
       have to use rootglob.

       Subdirectories  can  have their own .hgignore settings by adding	subin-
       clude:path/to/subdir/.hgignore to the root .hgignore. See hg help  pat-
       terns for details on subinclude:	and include:.

       Note   Patterns	specified  in  other than .hgignore are	always rooted.
	      Please see hg help patterns for details.

   Example
       Here is an example ignore file.

       # use glob syntax.
       syntax: glob

       *.elc
       *.pyc
       *~

       # switch	to regexp syntax.
       syntax: regexp
       ^\.pc/

CONFIGURING HGWEB
       Mercurial's internal web	server,	 hgweb,	 can  serve  either  a	single
       repository,  or	a tree of repositories.	In the second case, repository
       paths and global	options	can be defined using a dedicated configuration
       file common to hg serve,	hgweb.wsgi, hgweb.cgi and hgweb.fcgi.

       This  file  uses	the same syntax	as other Mercurial configuration files
       but recognizes only the following sections:

	  o web

	  o paths

	  o collections

       The web options are thoroughly described	in hg help config.

       The paths section maps URL  paths  to  paths  of	 repositories  in  the
       filesystem. hgweb will not expose the filesystem	directly - only	Mercu-
       rial repositories can be	published and only according to	the configura-
       tion.

       The  left  hand	side  is the path in the URL. Note that	hgweb reserves
       subpaths	like rev or file, try using different names for	nested reposi-
       tories to avoid confusing effects.

       The  right  hand	 side  is the path in the filesystem. If the specified
       path ends with *	or ** the filesystem will be searched recursively  for
       repositories  below  that  point.   With	* it will not recurse into the
       repositories it finds (except for .hg/patches).	With **	it  will  also
       search  inside  repository  working  directories	and possibly find sub-
       repositories.

       In this example:

       [paths]
       /projects/a = /srv/tmprepos/a
       /projects/b = c:/repos/b
       / = /srv/repos/*
       /user/bob = /home/bob/repos/**

       o The first two entries make two	repositories in	different  directories
	 appear	under the same directory in the	web interface

       o The  third  entry  will  publish  every Mercurial repository found in
	 /srv/repos/, for instance the repository /srv/repos/quux/ will	appear
	 as http://server/quux/

       o The  fourth  entry will publish both http://server/user/bob/quux/ and
	 http://server/user/bob/quux/testsubrepo/

       The collections section is deprecated and has been superseded by	paths.

   URLs	and Common Arguments
       URLs under each repository have the form	/{command}[/{arguments}] where
       {command}  represents  the name of a command or handler and {arguments}
       represents any number of	additional URL parameters to that command.

       The web server has a default style associated with it. Styles map to  a
       collection  of  named templates.	Each template is used to render	a spe-
       cific piece of data, such as a changeset	or diff.

       The style for the current request can be	overwritten two	 ways.	First,
       if  {command} contains a	hyphen (-), the	text before the	hyphen defines
       the style. For example, /atom-log will render the log  command  handler
       with  the atom style. The second	way to set the style is	with the style
       query string argument. For example, /log?style=atom. The	hyphenated URL
       parameter is preferred.

       Not  all	 templates  are	 available for all styles. Attempting to use a
       style that doesn't have all templates defined may result	 in  an	 error
       rendering the page.

       Many commands take a {revision} URL parameter. This defines the change-
       set to operate on. This is commonly specified as	the  short,  12	 digit
       hexadecimal  abbreviation  for  the  full  40 character unique revision
       identifier. However, any	value described	by hg help revisions typically
       works.

   Commands and	URLs
       The following web commands and their URLs are available:

   /annotate/{revision}/{path}
       Show changeset information for each line	in a file.

       The  ignorews,  ignorewsamount, ignorewseol, and	ignoreblanklines query
       string arguments	have the  same	meaning	 as  their  [annotate]	config
       equivalents.  It	 uses  the hgrc	boolean	parsing	logic to interpret the
       value. e.g. 0 and false are false and 1 and true	are true. If  not  de-
       fined, the server default settings are used.

       The fileannotate	template is rendered.

   /archive/{revision}.{format}[/{path}]
       Obtain an archive of repository content.

       The content and type of the archive is defined by a URL path parameter.
       format is the file extension of the archive type	to be generated.  e.g.
       zip  or	tar.bz2.  Not  all archive types may be	allowed	by your	server
       configuration.

       The optional path URL parameter controls	content	to include in the  ar-
       chive.  If  omitted, every file in the specified	revision is present in
       the archive. If included, only the specified file or  contents  of  the
       specified directory will	be included in the archive.

       No template is used for this handler. Raw, binary content is generated.

   /bookmarks
       Show information	about bookmarks.

       No arguments are	accepted.

       The bookmarks template is rendered.

   /branches
       Show information	about branches.

       All known branches are contained	in the output, even closed branches.

       No arguments are	accepted.

       The branches template is	rendered.

   /changelog[/{revision}]
       Show information	about multiple changesets.

       If  the optional	revision URL argument is absent, information about all
       changesets starting at tip will be rendered. If the  revision  argument
       is  present, changesets will be shown starting from the specified revi-
       sion.

       If revision is absent, the rev query string argument  may  be  defined.
       This will perform a search for changesets.

       The  argument  for  rev	can be a single	revision, a revision set, or a
       literal keyword to search for in	changeset data (equivalent to  hg  log
       -k).

       The  revcount  query  string  argument  defines	the maximum numbers of
       changesets to render.

       For non-searches, the changelog template	will be	rendered.

   /changeset[/{revision}]
       Show information	about a	single changeset.

       A URL path argument is the changeset identifier to show.	 See  hg  help
       revisions  for  possible	values.	If not defined,	the tip	changeset will
       be shown.

       The changeset template  is  rendered.  Contents	of  the	 changesettag,
       changesetbookmark, filenodelink,	filenolink, and	the many templates re-
       lated to	diffs may all be used to produce the output.

   /comparison/{revision}/{path}
       Show a comparison between the old and  new  versions  of	 a  file  from
       changes made on a particular revision.

       This  is	 similar  to  the  diff	handler. However, this form features a
       split or	side-by-side diff rather than a	unified	diff.

       The context query string	argument can be	used to	control	the  lines  of
       context in the diff.

       The filecomparison template is rendered.

   /diff/{revision}/{path}
       Show how	a file changed in a particular commit.

       The filediff template is	rendered.

       This  handler  is  registered under both	the /diff and /filediff	paths.
       /diff is	used in	modern code.

   /file/{revision}[/{path}]
       Show information	about a	directory or file in the repository.

       Info about the path given as a URL parameter will be rendered.

       If path is a directory, information about the entries in	that directory
       will be rendered. This form is equivalent to the	manifest handler.

       If  path	 is  a file, information about that file will be shown via the
       filerevision template.

       If path is not defined, information about the root  directory  will  be
       rendered.

   /diff/{revision}/{path}
       Show how	a file changed in a particular commit.

       The filediff template is	rendered.

       This  handler  is  registered under both	the /diff and /filediff	paths.
       /diff is	used in	modern code.

   /filelog/{revision}/{path}
       Show information	about the history of a file in the repository.

       The revcount query string argument can be defined to control the	 maxi-
       mum number of entries to	show.

       The filelog template will be rendered.

   /graph[/{revision}]
       Show information	about the graphical topology of	the repository.

       Information  rendered by	this handler can be used to create visual rep-
       resentations of repository topology.

       The revision URL	parameter controls the starting	changeset. If it's ab-
       sent, the default is tip.

       The  revcount query string argument can define the number of changesets
       to show information for.

       The graphtop query string argument can specify the  starting  changeset
       for producing jsdata variable that is used for rendering	graph in Java-
       Script. By default it has the same value	as revision.

       This handler will render	the graph template.

   /help[/{topic}]
       Render help documentation.

       This web	command	is roughly equivalent to hg help. If a	topic  is  de-
       fined,  that help topic will be rendered. If not, an index of available
       help topics will	be rendered.

       The help	template will be rendered when requesting help	for  a	topic.
       helptopics will be rendered for the index of help topics.

   /log[/{revision}[/{path}]]
       Show repository or file history.

       For  URLs of the	form /log/{revision}, a	list of	changesets starting at
       the specified changeset identifier is shown. If {revision} is  not  de-
       fined,  the  default  is	 tip. This form	is equivalent to the changelog
       handler.

       For URLs	of the form /log/{revision}/{file}, the	history	for a specific
       file will be shown. This	form is	equivalent to the filelog handler.

   /manifest[/{revision}[/{path}]]
       Show information	about a	directory.

       If  the	URL path arguments are omitted,	information about the root di-
       rectory for the tip changeset will be shown.

       Because this handler can	only show information for directories,	it  is
       recommended  to use the file handler instead, as	it can handle both di-
       rectories and files.

       The manifest template will be rendered for this handler.

   /changeset[/{revision}]
       Show information	about a	single changeset.

       A URL path argument is the changeset identifier to show.	 See  hg  help
       revisions  for  possible	values.	If not defined,	the tip	changeset will
       be shown.

       The changeset template  is  rendered.  Contents	of  the	 changesettag,
       changesetbookmark, filenodelink,	filenolink, and	the many templates re-
       lated to	diffs may all be used to produce the output.

   /shortlog
       Show basic information about a set of changesets.

       This accepts the	same parameters	as the	changelog  handler.  The  only
       difference  is  the  shortlog  template will be rendered	instead	of the
       changelog template.

   /summary
       Show a summary of repository state.

       Information about the latest changesets,	bookmarks, tags, and  branches
       is captured by this handler.

       The summary template is rendered.

   /tags
       Show information	about tags.

       No arguments are	accepted.

       The tags	template is rendered.

TECHNICAL IMPLEMENTATION TOPICS
       To access a subtopic, use "hg help internals.{subtopic-name}"

	  bundle2
		 Bundle2

	  bundles
		 Bundles

	  cbor	 CBOR

	  censor Censor

	  changegroups
		 Changegroups

	  config Config	Registrar

	  extensions
		 Extension API

	  mergestate
		 Mergestate

	  requirements
		 Repository Requirements

	  revlogs
		 Revision Logs

	  wireprotocol
		 Wire Protocol

	  wireprotocolrpc
		 Wire Protocol RPC

	  wireprotocolv2
		 Wire Protocol Version 2

MERGE TOOLS
       To merge	files Mercurial	uses merge tools.

       A  merge	 tool  combines	two different versions of a file into a	merged
       file. Merge tools are given the two files and the greatest  common  an-
       cestor of the two file versions,	so they	can determine the changes made
       on both branches.

       Merge tools are used both for hg	resolve, hg merge, hg update, hg back-
       out and in several extensions.

       Usually,	 the  merge tool tries to automatically	reconcile the files by
       combining all non-overlapping changes that occurred separately  in  the
       two  different  evolutions  of the same initial base file. Furthermore,
       some interactive	merge programs make it easier to manually resolve con-
       flicting	 merges,  either in a graphical	way, or	by inserting some con-
       flict markers. Mercurial	does not include any  interactive  merge  pro-
       grams but relies	on external tools for that.

   Available merge tools
       External	 merge	tools  and  their  properties  are  configured	in the
       merge-tools configuration section - see hgrc(5) - but  they  can	 often
       just be named by	their executable.

       A  merge	tool is	generally usable if its	executable can be found	on the
       system and if it	can handle the merge. The executable is	found if it is
       an  absolute  or	relative executable path or the	name of	an application
       in the executable search	path. The tool is assumed to be	able to	handle
       the merge if it can handle symlinks if the file is a symlink, if	it can
       handle binary files if the file is binary, and if a GUI is available if
       the tool	requires a GUI.

       There  are  some	 internal  merge tools which can be used. The internal
       merge tools are:

       :dump

	      Creates three versions of	the files  to  merge,  containing  the
	      contents	of local, other	and base. These	files can then be used
	      to perform a merge manually. If the file to be merged  is	 named
	      a.txt,  these  files  will  accordingly  be  named  a.txt.local,
	      a.txt.other and a.txt.base and they will be placed in  the  same
	      directory	as a.txt.

	      This  implies  premerge. Therefore, files	aren't dumped, if pre-
	      merge runs successfully. Use :forcedump to forcibly write	 files
	      out.

	      (actual capabilities: binary, symlink)

       :fail

	      Rather than attempting to	merge files that were modified on both
	      branches,	it marks them as unresolved. The resolve command  must
	      be used to resolve these conflicts.

	      (actual capabilities: binary, symlink)

       :forcedump

	      Creates  three versions of the files as same as :dump, but omits
	      premerge.

	      (actual capabilities: binary, symlink)

       :local

	      Uses the local p1() version of files as the merged version.

	      (actual capabilities: binary, symlink)

       :merge

	      Uses the internal	non-interactive	 simple	 merge	algorithm  for
	      merging files. It	will fail if there are any conflicts and leave
	      markers in the partially merged file. Markers will have two sec-
	      tions, one for each side of merge.

       :merge-local

	      Like  :merge, but	resolve	all conflicts non-interactively	in fa-
	      vor of the local p1() changes.

       :merge-other

	      Like :merge, but resolve all conflicts non-interactively in  fa-
	      vor of the other p2() changes.

       :merge3

	      Uses  the	 internal  non-interactive  simple merge algorithm for
	      merging files. It	will fail if there are any conflicts and leave
	      markers  in  the	partially  merged file.	Marker will have three
	      sections,	one from each side of the merge	and one	for  the  base
	      content.

       :other

	      Uses the other p2() version of files as the merged version.

	      (actual capabilities: binary, symlink)

       :prompt

	      Asks  the	user which of the local	p1() or	the other p2() version
	      to keep as the merged version.

	      (actual capabilities: binary, symlink)

       :tagmerge

	      Uses the internal	tag merge algorithm (experimental).

       :union

	      Uses the internal	non-interactive	 simple	 merge	algorithm  for
	      merging  files.  It  will	use both left and right	sides for con-
	      flict regions.  No markers are inserted.

       Internal	tools are always available and do not require a	GUI  but  will
       by  default  not	 handle	symlinks or binary files. See next section for
       detail about "actual capabilities" described above.

   Choosing a merge tool
       Mercurial uses these rules when deciding	which merge tool to use:

       1. If a tool has	been specified with the	--tool option to merge or  re-
	  solve,  it  is used.	If it is the name of a tool in the merge-tools
	  configuration, its configuration is used.  Otherwise	the  specified
	  tool must be executable by the shell.

       2. If  the  HGMERGE  environment	variable is present, its value is used
	  and must be executable by the	shell.

       3. If the filename of the file to be merged matches any of the patterns
	  in  the merge-patterns configuration section,	the first usable merge
	  tool corresponding to	a matching pattern is used.

       4. If ui.merge is set it	will be	considered next. If the	value  is  not
	  the  name of a configured tool, the specified	value is used and must
	  be executable	by the shell. Otherwise	the named tool is used	if  it
	  is usable.

       5. If  any usable merge tools are present in the	merge-tools configura-
	  tion section,	the one	with the highest priority is used.

       6. If a program named hgmerge can be found on the system, it is used  -
	  but it will by default not be	used for symlinks and binary files.

       7. If  the  file	 to be merged is not binary and	is not a symlink, then
	  internal :merge is used.

       8. Otherwise, :prompt is	used.

       For historical reason, Mercurial	treats merge tools as below while  ex-
       amining rules above.

		  +-----------+----------------+--------+---------+
		  |step	      |	specified via  | binary	| symlink |
		  +-----------+----------------+--------+---------+
		  |	      |	--tool	       | o/o	| o/o	  |
		  |	  1.  |		       |	|	  |
		  +-----------+----------------+--------+---------+
		  |	      |	HGMERGE	       | o/o	| o/o	  |
		  |	  2.  |		       |	|	  |
		  +-----------+----------------+--------+---------+
		  |	      |	merge-patterns | o/o(*)	| x/?(*)  |
		  |	  3.  |		       |	|	  |
		  +-----------+----------------+--------+---------+
		  |	      |	ui.merge       | x/?(*)	| x/?(*)  |
		  |	  4.  |		       |	|	  |
		  +-----------+----------------+--------+---------+

       Each capability column indicates	Mercurial behavior for internal/exter-
       nal merge tools at examining each rule.

       o "o": "assume that a tool has capability"

       o "x": "assume that a tool does not have	capability"

       o "?": "check actual capability of a tool"

       If  merge.strict-capability-check  configuration	 is  true,   Mercurial
       checks  capabilities of merge tools strictly in (*) cases above (= each
       capability column becomes "?/?"). It is false by	default	 for  backward
       compatibility.

       Note   After  selecting	a merge	program, Mercurial will	by default at-
	      tempt to merge the files using a simple merge  algorithm	first.
	      Only  if	it doesn't succeed because of conflicting changes will
	      Mercurial	actually execute the merge program. Whether to use the
	      simple  merge  algorithm first can be controlled by the premerge
	      setting of the merge tool. Premerge is enabled by	default	unless
	      the file is binary or a symlink.

       See  the	merge-tools and	ui sections of hgrc(5) for details on the con-
       figuration of merge tools.

PAGER SUPPORT
       Some Mercurial commands can produce a lot of output, and	Mercurial will
       attempt to use a	pager to make those commands more pleasant.

       To set the pager	that should be used, set the application variable:

       [pager]
       pager = less -FRX

       If  no  pager is	set in the user	or repository configuration, Mercurial
       uses the	environment variable $PAGER. If	$PAGER is not set, pager.pager
       from  the default or system configuration is used. If none of these are
       set, a default pager will be used, typically less on Unix and  more  on
       Windows.

       On  Windows,  more is not color aware, so using it effectively disables
       color.  MSYS and	Cygwin shells provide less as a	pager,	which  can  be
       configured   to	 support   ANSI	  color	  codes.   See	hg  help  con-
       fig.color.pagermode to configure	the color mode when invoking a pager.

       You can disable the pager for certain commands by adding	 them  to  the
       pager.ignore list:

       [pager]
       ignore =	version, help, update

       To ignore global	commands like hg version or hg help, you have to spec-
       ify them	in your	user configuration file.

       To control whether the pager is used at all for an individual  command,
       you can use --pager=<value>:

	  o use	as needed: auto.

	  o require the	pager: yes or on.

	  o suppress  the  pager:  no or off (any unrecognized value will also
	    work).

       To globally turn	off all	attempts to use	a pager, set:

       [ui]
       paginate	= never

       which will prevent the pager from running.

FILE NAME PATTERNS
       Mercurial accepts several notations for identifying one or  more	 files
       at a time.

       By  default,  Mercurial	treats	filenames as shell-style extended glob
       patterns.

       Alternate pattern notations must	be specified explicitly.

       Note   Patterns specified in .hgignore are not rooted.  Please  see  hg
	      help hgignore for	details.

       To  use	a  plain path name without any pattern matching, start it with
       path:. These path names must completely match starting at  the  current
       repository root,	and when the path points to a directory, it is matched
       recursively. To match all files in a directory non-recursively (not in-
       cluding	any files in subdirectories), rootfilesin: can be used,	speci-
       fying an	absolute path (relative	to the repository root).

       To use an extended glob,	start a	name with glob:. Globs are  rooted  at
       the  current directory; a glob such as *.c will only match files	in the
       current directory ending	with .c. rootglob:  can	 be  used  instead  of
       glob: for a glob	that is	rooted at the root of the repository.

       The  supported glob syntax extensions are ** to match any string	across
       path separators and {a,b} to mean "a or b".

       To use a	Perl/Python regular expression,	start a	name with re:.	Regexp
       pattern matching	is anchored at the root	of the repository.

       To  read	 name  patterns	from a file, use listfile: or listfile0:.  The
       latter expects null delimited patterns while the	 former	 expects  line
       feeds.  Each string read	from the file is itself	treated	as a file pat-
       tern.

       To read a set of	patterns from a	file,  use  include:  or  subinclude:.
       include:	 will  use all the patterns from the given file	and treat them
       as if they had been passed in manually.	subinclude:  will  only	 apply
       the  patterns against files that	are under the subinclude file's	direc-
       tory. See hg help hgignore for details on the format of these files.

       All patterns, except for	glob: specified	in command line	(not for -I or
       -X  options),  can  match also against directories: files under matched
       directories are treated as matched.  For	-I and -X options, glob:  will
       match directories recursively.

       Plain examples:

       path:foo/bar	   a name bar in a directory named foo in the root
			   of the repository
       path:path:name	   a file or directory named "path:name"
       rootfilesin:foo/bar the files in	a directory called foo/bar, but	not any	files
			   in its subdirectories and not a file	bar in directory foo

       Glob examples:

       glob:*.c	      any name ending in ".c" in the current directory
       *.c	      any name ending in ".c" in the current directory
       **.c	      any name ending in ".c" in any subdirectory of the
		      current directory	including itself.
       foo/*	      any file in directory foo
       foo/**	      any file in directory foo	plus all its subdirectories,
		      recursively
       foo/*.c	      any name ending in ".c" in the directory foo
       foo/**.c	      any name ending in ".c" in any subdirectory of foo
		      including	itself.
       rootglob:*.c   any name ending in ".c" in the root of the repository

       Regexp examples:

       re:.*\.c$      any name ending in ".c", anywhere	in the repository

       File examples:

       listfile:list.txt  read list from list.txt with one file	pattern	per line
       listfile0:list.txt read list from list.txt with null byte delimiters

       See also	hg help	filesets.

       Include examples:

       include:path/to/mypatternfile	reads patterns to be applied to	all paths
       subinclude:path/to/subignorefile	reads patterns specifically for	paths in the
					subdirectory

WORKING	WITH PHASES
   What	are phases?
       Phases  are  a system for tracking which	changesets have	been or	should
       be shared. This helps prevent common mistakes  when  modifying  history
       (for instance, with the mq or rebase extensions).

       Each changeset in a repository is in one	of the following phases:

	  o public : changeset is visible on a public server

	  o draft : changeset is not yet published

	  o secret : changeset should not be pushed, pulled, or	cloned

       These phases are	ordered	(public	< draft	< secret) and no changeset can
       be in a lower phase than	its ancestors. For instance, if	a changeset is
       public,	all  its  ancestors  are also public. Lastly, changeset	phases
       should only be changed towards the public phase.

   How are phases managed?
       For the most part, phases should	 work  transparently.  By  default,  a
       changeset  is  created  in the draft phase and is moved into the	public
       phase when it is	pushed to another repository.

       Once changesets become public,  extensions  like	 mq  and  rebase  will
       refuse  to  operate  on	them to	prevent	creating duplicate changesets.
       Phases can also be manually manipulated with the	 hg  phase command  if
       needed. See hg help -v phase for	examples.

       To  make	your commits secret by default,	put this in your configuration
       file:

       [phases]
       new-commit = secret

   Phases and servers
       Normally, all servers are publishing by default.	This means:

       - all draft changesets that are pulled or cloned	appear in phase
       public on the client

       - all draft changesets that are pushed appear as	public on both
       client and server

       - secret	changesets are neither pushed, pulled, or cloned

       Note   Pulling a	draft changeset	from a publishing server does not mark
	      it  as  public on	the server side	due to the read-only nature of
	      pull.

       Sometimes it may	be desirable to	push and pull changesets in the	 draft
       phase  to  share	unfinished work. This can be done by setting a reposi-
       tory to disable publishing in its configuration file:

       [phases]
       publish = False

       See hg help config for more information on configuration	files.

       Note   Servers running older versions of	Mercurial are treated as  pub-
	      lishing.

       Note   Changesets  in  secret  phase are	not exchanged with the server.
	      This applies to their content: file names,  file	contents,  and
	      changeset	 metadata. For technical reasons, the identifier (e.g.
	      d825e4025e39) of the secret changeset may	be communicated	to the
	      server.

   Examples
	  o list changesets in draft or	secret phase:

	    hg log -r "not public()"

	  o change all secret changesets to draft:

	    hg phase --draft "secret()"

	  o forcibly move the current changeset	and descendants	from public to
	    draft:

	    hg phase --force --draft .

	  o show a list	of changeset revisions and each	corresponding phase:

	    hg log --template "{rev} {phase}\n"

	  o resynchronize draft	changesets relative to a remote	repository:

	    hg phase -fd "outgoing(URL)"

       See hg help phase for more information on manually manipulating phases.

SPECIFYING REVISIONS
       Mercurial supports several ways to specify revisions.

   Specifying single revisions
       A plain integer is treated as a revision	number.	Negative integers  are
       treated	as  sequential offsets from the	tip, with -1 denoting the tip,
       -2 denoting the revision	prior to the tip, and so forth.

       A 40-digit hexadecimal string is	treated	as a unique  revision  identi-
       fier.   A hexadecimal string less than 40 characters long is treated as
       a unique	revision identifier and	is referred to as a short-form identi-
       fier.  A	short-form identifier is only valid if it is the prefix	of ex-
       actly one full-length identifier.

       Any other string	is treated as a	bookmark, tag, or branch name. A book-
       mark  is	a movable pointer to a revision. A tag is a permanent name as-
       sociated	with a revision. A branch name denotes the tipmost open	branch
       head  of	 that  branch  - or if they are	all closed, the	tipmost	closed
       head of the branch. Bookmark, tag, and branch names  must  not  contain
       the ":" character.

       The reserved name "tip" always identifies the most recent revision.

       The reserved name "null"	indicates the null revision. This is the revi-
       sion of an empty	repository, and	the parent of revision 0.

       The reserved name "." indicates the working  directory  parent.	If  no
       working	directory  is checked out, it is equivalent to null. If	an un-
       committed merge is in progress, "." is the revision of the  first  par-
       ent.

       Finally,	 commands  that	expect a single	revision (like hg update) also
       accept revsets (see below for details). When given a revset,  they  use
       the last	revision of the	revset.	A few commands accept two single revi-
       sions (like hg diff). When given	a revset, they use the first  and  the
       last revisions of the revset.

   Specifying multiple revisions
       Mercurial  supports  a functional language for selecting	a set of revi-
       sions. Expressions in this language are called revsets.

       The language supports a number of predicates which are joined by	 infix
       operators. Parenthesis can be used for grouping.

       Identifiers such	as branch names	may need quoting with single or	double
       quotes if they contain characters like -	or if they match  one  of  the
       predefined predicates.

       Special	characters can be used in quoted identifiers by	escaping them,
       e.g., \n	is interpreted as a newline. To	prevent	them from being	inter-
       preted, strings can be prefixed with r, e.g. r'...'.

   Operators
       There is	a single prefix	operator:

       not x

	      Changesets not in	x. Short form is ! x.

       These are the supported infix operators:

       x::y

	      A	 DAG  range,  meaning all changesets that are descendants of x
	      and ancestors of y, including x and y themselves.	If  the	 first
	      endpoint is left out, this is equivalent to ancestors(y),	if the
	      second is	left out it is equivalent to descendants(x).

	      An alternative syntax is x..y.

       x:y

	      All changesets with revision numbers between x and y,  both  in-
	      clusive.	Either endpoint	can be left out, they default to 0 and
	      tip.

       x and y

	      The intersection of changesets in	x and y. Short form is x & y.

       x or y

	      The union	of changesets in x and y. There	 are  two  alternative
	      short forms: x | y and x + y.

       x - y

	      Changesets in x but not in y.

       x % y

	      Changesets  that are ancestors of	x but not ancestors of y (i.e.
	      ::x - ::y).  This	is shorthand notation for only(x, y) (see  be-
	      low).  The  second  argument  is	optional  and, if left out, is
	      equivalent to only(x).

       x^n

	      The nth parent of	x, n ==	0, 1, or 2.  For n == 0, x; for	 n  ==
	      1, the first parent of each changeset in x; for n	== 2, the sec-
	      ond parent of changeset in x.

       x~n

	      The nth first ancestor of	x; x~0 is x; x~3 is x^^^.  For n <  0,
	      the nth unambiguous descendent of	x.

       x ## y

	      Concatenate strings and identifiers into one string.

	      All  other prefix, infix and postfix operators have lower	prior-
	      ity than ##. For example,	a1 ## a2~2 is  equivalent  to  (a1  ##
	      a2)~2.

	      For example:

	      [revsetalias]
	      issue(a1)	= grep(r'\bissue[ :]?' ## a1 ##	r'\b|\bbug\(' ## a1 ## r'\)')

	      issue(1234)      is      equivalent      to      grep(r'\bissue[
	      :]?1234\b|\bbug\(1234\)')	in this	case. This matches against all
	      of "issue	1234", "issue:1234", "issue1234" and "bug(1234)".

       There is	a single postfix operator:

       x^

	      Equivalent to x^1, the first parent of each changeset in x.

   Patterns
       Where  noted, predicates	that perform string matching can accept	a pat-
       tern string. The	pattern	may be either a	literal, or a regular  expres-
       sion.  If  the pattern starts with re:, the remainder of	the pattern is
       treated as a regular expression.	Otherwise, it is treated as a literal.
       To  match  a pattern that actually starts with re:, use the prefix lit-
       eral:.

       Matching	is case-sensitive, unless otherwise noted.  To perform a case-
       insensitive  match on a case-sensitive predicate, use a regular expres-
       sion, prefixed with (?i).

       For example, tag(r're:(?i)release') matches "release" or	 "RELEASE"  or
       "Release", etc.

   Predicates
       The following predicates	are supported:

       adds(pattern)

	      Changesets that add a file matching pattern.

	      The  pattern  without explicit kind like glob: is	expected to be
	      relative to the current directory	and match against a file or  a
	      directory.

       all()

	      All changesets, the same as 0:tip.

       ancestor(*changeset)

	      A	greatest common	ancestor of the	changesets.

	      Accepts  0  or  more  changesets.	  Will	return empty list when
	      passed no	args.  Greatest	common ancestor	of a single  changeset
	      is that changeset.

       ancestors(set[, depth])

	      Changesets  that	are  ancestors of changesets in	set, including
	      the given	changesets themselves.

	      If depth is specified, the result	only includes changesets up to
	      the specified generation.

       author(string)

	      Alias for	user(string).

       bisect(string)

	      Changesets marked	in the specified bisect	status:

	      o	good, bad, skip: csets explicitly marked as good/bad/skip

	      o	goods, bads	 : csets topologically good/bad

	      o	range		   : csets taking part in the bisection

	      o	pruned		   : csets that	are goods, bads	or skipped

	      o	untested	   : csets whose fate is yet unknown

	      o	ignored		   : csets ignored due to DAG topology

	      o	current		   : the cset currently	being bisected

       bookmark([name])

	      The named	bookmark or all	bookmarks.

	      Pattern  matching	 is  supported	for  name.  See	 hg help revi-
	      sions.patterns.

       branch(string or	set)

	      All changesets belonging to the given branch or the branches  of
	      the given	changesets.

	      Pattern  matching	 is  supported	for  string. See hg help revi-
	      sions.patterns.

       branchpoint()

	      Changesets with more than	one child.

       bundle()

	      Changesets in the	bundle.

	      Bundle must be specified by the -R option.

       children(set)

	      Child changesets of changesets in	set.

       closed()

	      Changeset	is closed.

       commonancestors(set)

	      Changesets that are ancestors of every changeset in set.

       contains(pattern)

	      The revision's manifest contains a file  matching	 pattern  (but
	      might not	modify it). See	hg help	patterns for information about
	      file patterns.

	      The pattern without explicit kind	like glob: is expected	to  be
	      relative	to  the	current	directory and match against a file ex-
	      actly for	efficiency.

       converted([id])

	      Changesets converted from	the given identifier in	the old	repos-
	      itory  if	 present, or all converted changesets if no identifier
	      is specified.

       date(interval)

	      Changesets within	the interval, see hg help dates.

       desc(string)

	      Search commit message for	string.	The match is case-insensitive.

	      Pattern matching is supported for	 string.  See  hg  help	 revi-
	      sions.patterns.

       descendants(set[, depth])

	      Changesets which are descendants of changesets in	set, including
	      the given	changesets themselves.

	      If depth is specified, the result	only includes changesets up to
	      the specified generation.

       destination([set])

	      Changesets  that	were  created by a graft, transplant or	rebase
	      operation, with the given	revisions  specified  as  the  source.
	      Omitting the optional set	is the same as passing all().

       draft()

	      Changeset	in draft phase.

       expectsize(set[,	size])

	      Return  the given	revset if size matches the revset size.	 Abort
	      if the revset doesn't expect given size.	size can either	be  an
	      integer range or an integer.

	      For example, expectsize(0:1, 3:5)	will abort as revset size is 2
	      and 2 is not between 3 and 5 inclusive.

       extinct()

	      Obsolete changesets with obsolete	descendants only.

       extra(label, [value])

	      Changesets with the given	label in the extra metadata, with  the
	      given optional value.

	      Pattern  matching	 is  supported	for  value.  See hg help revi-
	      sions.patterns.

       file(pattern)

	      Changesets affecting files matched by pattern.

	      For a faster but less accurate result, consider using  filelog()
	      instead.

	      This predicate uses glob:	as the default kind of pattern.

       filelog(pattern)

	      Changesets connected to the specified filelog.

	      For  performance reasons,	visits only revisions mentioned	in the
	      file-level filelog, rather than filtering	through	all changesets
	      (much faster, but	doesn't	include	deletes	or duplicate changes).
	      For a slower, more accurate result, use file().

	      The pattern without explicit kind	like glob: is expected	to  be
	      relative	to  the	current	directory and match against a file ex-
	      actly for	efficiency.

       first(set, [n])

	      An alias for limit().

       follow([file[, startrev]])

	      An alias for ::. (ancestors of  the  working  directory's	 first
	      parent).	 If  file pattern is specified,	the histories of files
	      matching given pattern in	the revision  given  by	 startrev  are
	      followed,	including copies.

       followlines(file, fromline:toline[, startrev=., descend=False])

	      Changesets modifying file	in line	range ('fromline', 'toline').

	      Line  range  corresponds	to  'file'  content  at	'startrev' and
	      should hence be consistent with file size. If  startrev  is  not
	      specified, working directory's parent is used.

	      By  default,  ancestors of 'startrev' are	returned. If 'descend'
	      is True, descendants of 'startrev' are returned  though  renames
	      are (currently) not followed in this direction.

       grep(regex)

	      Like  keyword(string)  but  accepts a regex. Use grep(r'...') to
	      ensure special escape characters are handled  correctly.	Unlike
	      keyword(string), the match is case-sensitive.

       head()

	      Changeset	is a named branch head.

       heads(set)

	      Members of set with no children in set.

       hidden()

	      Hidden changesets.

       id(string)

	      Revision	non-ambiguously	specified by the given hex string pre-
	      fix.

       keyword(string)

	      Search commit message, user name,	and names of changed files for
	      string. The match	is case-insensitive.

	      For  a  regular  expression  or  case  sensitive search of these
	      fields, use grep(regex).

       last(set, [n])

	      Last n members of	set, defaulting	to 1.

       limit(set[, n[, offset]])

	      First n members of set, defaulting to 1, starting	from offset.

       matching(revision [, field])

	      Changesets in which a given set  of  fields  match  the  set  of
	      fields in	the selected revision or set.

	      To  match	 more  than one	field pass the list of fields to match
	      separated	by spaces (e.g.	author description).

	      Valid fields are most regular revision fields and	 some  special
	      fields.

	      Regular  revision	 fields	are description, author, branch, date,
	      files, phase, parents, substate, user and	diff.  Note  that  au-
	      thor  and	 user are synonyms. diff refers	to the contents	of the
	      revision.	Two revisions matching	their  diff  will  also	 match
	      their files.

	      Special  fields  are  summary  and metadata: summary matches the
	      first line of the	description.  metadata is equivalent to	match-
	      ing  description	user  date  (i.e. it matches the main metadata
	      fields).

	      metadata is the default field which is used when no  fields  are
	      specified. You can match more than one field at a	time.

       max(set)

	      Changeset	with highest revision number in	set.

       merge()

	      Changeset	is a merge changeset.

       min(set)

	      Changeset	with lowest revision number in set.

       modifies(pattern)

	      Changesets modifying files matched by pattern.

	      The  pattern  without explicit kind like glob: is	expected to be
	      relative to the current directory	and match against a file or  a
	      directory.

       named(namespace)

	      The changesets in	a given	namespace.

	      Pattern  matching	 is supported for namespace. See hg help revi-
	      sions.patterns.

       none()

	      No changesets.

       obsolete()

	      Mutable changeset	with a newer version.

       only(set, [set])

	      Changesets that are ancestors of the first set that are not  an-
	      cestors of any other head	in the repo. If	a second set is	speci-
	      fied, the	result is ancestors of the first set that are not  an-
	      cestors of the second set	(i.e. ::<set1> - ::<set2>).

       origin([set])

	      Changesets  that	were  specified	 as  a	source for the grafts,
	      transplants or rebases that created the given revisions.	 Omit-
	      ting  the	 optional  set	is  the	 same  as passing all().  If a
	      changeset	created	by these operations is itself specified	 as  a
	      source  for  one	of these operations, only the source changeset
	      for the first operation is selected.

       outgoing([path])

	      Changesets not found in the specified destination	repository, or
	      the default push location.

       p1([set])

	      First parent of changesets in set, or the	working	directory.

       p2([set])

	      Second parent of changesets in set, or the working directory.

       parents([set])

	      The set of all parents for all changesets	in set,	or the working
	      directory.

       present(set)

	      An empty set, if any revision in set isn't found;	otherwise, all
	      revisions	in set.

	      If any of	specified revisions is not present in the local	repos-
	      itory, the query is normally aborted. But	this predicate	allows
	      the query	to continue even in such cases.

       public()

	      Changeset	in public phase.

       remote([id [,path]])

	      Local revision that corresponds to the given identifier in a re-
	      mote repository, if present. Here, the '.' identifier is a  syn-
	      onym for the current local branch.

       removes(pattern)

	      Changesets which remove files matching pattern.

	      The  pattern  without explicit kind like glob: is	expected to be
	      relative to the current directory	and match against a file or  a
	      directory.

       rev(number)

	      Revision with the	given numeric identifier.

       reverse(set)

	      Reverse order of set.

       revset(set)

	      Strictly interpret the content as	a revset.

	      The  content  of	this special predicate will be strictly	inter-
	      preted as	a revset. For example, revset(id(0))  will  be	inter-
	      preted  as  "id(0)"  without  possible  ambiguity	with a "id(0)"
	      bookmark or tag.

       roots(set)

	      Changesets in set	with no	parent changeset in set.

       secret()

	      Changeset	in secret phase.

       sort(set[, [-]key... [, ...]])

	      Sort set by keys.	The default sort order is ascending, specify a
	      key as -key to sort in descending	order.

	      The keys can be:

	      o	rev for	the revision number,

	      o	branch for the branch name,

	      o	desc for the commit message (description),

	      o	user for user name (author can be used as an alias),

	      o	date for the commit date

	      o	topo for a reverse topographical sort

	      The  topo	 sort  order  cannot be	combined with other sort keys.
	      This sort	takes one optional argument,  topo.firstbranch,	 which
	      takes  a	revset	that  specifies	what topographical branches to
	      prioritize in the	sort.

       subrepo([pattern])

	      Changesets that add, modify or remove the	given subrepo.	If  no
	      subrepo pattern is named,	any subrepo changes are	returned.

       successors(set)

	      All successors for set, including	the given set themselves

       tag([name])

	      The specified tag	by name, or all	tagged revisions if no name is
	      given.

	      Pattern matching is  supported  for  name.  See  hg  help	 revi-
	      sions.patterns.

       user(string)

	      User name	contains string. The match is case-insensitive.

	      Pattern  matching	 is  supported	for  string. See hg help revi-
	      sions.patterns.

   Aliases
       New predicates (known as	"aliases") can be defined, using any  combina-
       tion of existing	predicates or other aliases. An	alias definition looks
       like:

       <alias> = <definition>

       in the revsetalias section of a Mercurial configuration file. Arguments
       of  the form a1,	a2, etc. are substituted from the alias	into the defi-
       nition.

       For example,

       [revsetalias]
       h = heads()
       d(s) = sort(s, date)
       rs(s, k)	= reverse(sort(s, k))

       defines three aliases, h, d,  and  rs.  rs(0:tip,  author)  is  exactly
       equivalent to reverse(sort(0:tip, author)).

   Equivalents
       Command line equivalents	for hg log:

       -f    ->	 ::.
       -d x  ->	 date(x)
       -k x  ->	 keyword(x)
       -m    ->	 merge()
       -u x  ->	 user(x)
       -b x  ->	 branch(x)
       -P x  ->	 !::x
       -l x  ->	 limit(expr, x)

   Examples
       Some sample queries:

       o Changesets on the default branch:

	 hg log	-r "branch(default)"

       o Changesets on the default branch since	tag 1.5	(excluding merges):

	 hg log	-r "branch(default) and	1.5:: and not merge()"

       o Open branch heads:

	 hg log	-r "head() and not closed()"

       o Changesets  between  tags  1.3	 and  1.5 mentioning "bug" that	affect
	 hgext/*:

	 hg log	-r "1.3::1.5 and keyword(bug) and file('hgext/*')"

       o Changesets committed in May 2008, sorted by user:

	 hg log	-r "sort(date('May 2008'), user)"

       o Changesets mentioning "bug" or	"issue"	that are not in	a  tagged  re-
	 lease:

	 hg log	-r "(keyword(bug) or keyword(issue)) and not ancestors(tag())"

       o Update	to the commit that bookmark @ is pointing to, without activat-
	 ing the bookmark (this	works because the last revision	of the	revset
	 is used):

	 hg update :@

       o Show  diff between tags 1.3 and 1.5 (this works because the first and
	 the last revisions of the revset are used):

	 hg diff -r 1.3::1.5

USING MERCURIAL	FROM SCRIPTS AND AUTOMATION
       It is common for	machines (as opposed to	humans)	to consume  Mercurial.
       This  help  topic  describes some of the	considerations for interfacing
       machines	with Mercurial.

   Choosing an Interface
       Machines	have a choice of several methods to interface with  Mercurial.
       These include:

       o Executing the hg process

       o Querying a HTTP server

       o Calling out to	a command server

       Executing hg processes is very similar to how humans interact with Mer-
       curial in the shell. It should already be familiar to you.

       hg serve	can be used to start a server. By default, this	will  start  a
       "hgweb"	HTTP server. This HTTP server has support for machine-readable
       output, such as JSON. For more, see hg help hgweb.

       hg serve	can also start a "command server." Clients can connect to this
       server  and issue Mercurial commands over a special protocol.  For more
       details on the command server, including	links to client	libraries, see
       https://www.mercurial-scm.org/wiki/CommandServer.

       hg  serve based interfaces (the hgweb and command servers) have the ad-
       vantage over simple hg process invocations in that they are likely more
       efficient.  This	 is because there is significant overhead to spawn new
       Python processes.

       Tip    If you need to invoke several hg processes in short order	and/or
	      performance is important to you, use of a	server-based interface
	      is highly	recommended.

   Environment Variables
       As documented in	hg help	environment, various environment variables in-
       fluence the operation of	Mercurial. The following are particularly rel-
       evant for machines consuming Mercurial:

       HGPLAIN
	      If not set, Mercurial's output could be influenced by configura-
	      tion  settings that impact its encoding, verbose mode, localiza-
	      tion, etc.

	      It is highly recommended for machines to set this	variable  when
	      invoking hg processes.

       HGENCODING
	      If  not  set, the	locale used by Mercurial will be detected from
	      the environment. If the determined locale	does not support  dis-
	      play of certain characters, Mercurial may	render these character
	      sequences	incorrectly (often by using "?"	as a  placeholder  for
	      invalid characters in the	current	locale).

	      Explicitly  setting this environment variable is a good practice
	      to guarantee consistent results. "utf-8" is  a  good  choice  on
	      UNIX-like	environments.

       HGRCPATH
	      If  not  set,  Mercurial will inherit config options from	config
	      files using the process described	in hg help  config.  This  in-
	      cludes inheriting	user or	system-wide config files.

	      When utmost control over the Mercurial configuration is desired,
	      the value	of HGRCPATH can	be set to an explicit file with	 known
	      good  configs.  In  rare cases, the value	can be set to an empty
	      file or the null device (often /dev/null)	to bypass  loading  of
	      any  user	or system config files.	Note that these	approaches can
	      have unintended consequences, as	the  user  and	system	config
	      files  often define things like the username and extensions that
	      may be required to interface with	a repository.

   Command-line	Flags
       Mercurial's default command-line	parser is designed for humans, and  is
       not  robust  against malicious input. For instance, you can start a de-
       bugger by passing --debugger as an option value:

       $ REV=--debugger	sh -c 'hg log -r "$REV"'

       This happens because several command-line  flags	 need  to  be  scanned
       without	using  a  concrete  command table, which may be	modified while
       loading repository settings and extensions.

       Since Mercurial 4.4.2, the parsing of such flags	may be	restricted  by
       setting	HGPLAIN=+strictflags.  When this feature is enabled, all early
       options (e.g. -R/--repository, --cwd, --config) must be specified first
       amongst	the  other  global options, and	cannot be injected to an arbi-
       trary location:

       $ HGPLAIN=+strictflags hg -R "$REPO" log	-r "$REV"

       In earlier Mercurial versions where +strictflags	isn't  available,  you
       can mitigate the	issue by concatenating an option value with its	flag:

       $ hg log	-r"$REV" --keyword="$KEYWORD"

   Consuming Command Output
       It is common for	machines to need to parse the output of	Mercurial com-
       mands for relevant data.	This section describes the various  techniques
       for doing so.

   Parsing Raw Command Output
       Likely  the  simplest and most effective	solution for consuming command
       output is to simply invoke hg commands as you would as a	user and parse
       their output.

       The  output of many commands can	easily be parsed with tools like grep,
       sed, and	awk.

       A potential downside with parsing command output	is that	the output  of
       commands	 can  change  when Mercurial is	upgraded. While	Mercurial does
       generally strive	for strong  backwards  compatibility,  command	output
       does  occasionally change. Having tests for your	automated interactions
       with hg commands	is generally recommended, but is even  more  important
       when raw	command	output parsing is involved.

   Using Templates to Control Output
       Many hg commands	support	templatized output via the -T/--template argu-
       ment. For more, see hg help templates.

       Templates are useful for	explicitly controlling output so that you  get
       exactly	the  data you want formatted how you want it. For example, log
       -T {node}\n can be used to print	a newline delimited list of  changeset
       nodes instead of	a human-tailored output	containing authors, dates, de-
       scriptions, etc.

       Tip    If parsing raw command output is too complicated,	consider using
	      templates	to make	your life easier.

       The  -T/--template argument allows specifying pre-defined styles.  Mer-
       curial ships with the machine-readable  styles  cbor,  json,  and  xml,
       which provide CBOR, JSON, and XML output, respectively.	These are use-
       ful for producing output	that is	machine	readable as-is.

       (Mercurial 5.0 is required for CBOR style.)

       Important
	      The json and xml styles are considered experimental. While  they
	      may  be  attractive to use for easily obtaining machine-readable
	      output, their behavior may change	in subsequent versions.

	      These styles may also exhibit unexpected	results	 when  dealing
	      with  certain  encodings.	Mercurial treats things	like filenames
	      as a series of bytes and normalizing certain byte	 sequences  to
	      JSON  or	XML  with  certain  encoding settings can lead to sur-
	      prises.

   Command Server Output
       If using	the command server to interact with Mercurial, you are	likely
       using  an existing library/API that abstracts implementation details of
       the command server. If so, this interface layer may perform parsing for
       you, saving you the work	of implementing	it yourself.

   Output Verbosity
       Commands	 often	have varying output verbosity, even when machine read-
       able styles are being used (e.g.	 -T  json).  Adding  -v/--verbose  and
       --debug	to the command's arguments can increase	the amount of data ex-
       posed by	Mercurial.

       An alternate way	to get the data	you need is by explicitly specifying a
       template.

   Other Topics
       revsets
	      Revisions	 sets  is  a functional	query language for selecting a
	      set of revisions.	Think of it as SQL for Mercurial repositories.
	      Revsets are useful for querying repositories for specific	data.

	      See hg help revsets for more.

       share extension
	      The  share  extension provides functionality for sharing reposi-
	      tory data	across several working copies. It can  even  automati-
	      cally  "pool"  storage  for  logically related repositories when
	      cloning.

	      Configuring the share extension can lead to significant resource
	      utilization  reduction,  particularly  around disk space and the
	      network. This is especially true for continuous integration (CI)
	      environments.

	      See hg help -e share for more.

SUBREPOSITORIES
       Subrepositories	let  you nest external repositories or projects	into a
       parent Mercurial	repository, and	make commands operate  on  them	 as  a
       group.

       Mercurial  currently supports Mercurial,	Git, and Subversion subreposi-
       tories.

       Subrepositories are made	of three components:

       1. Nested repository checkouts. They can	appear anywhere	in the	parent
	  working directory.

       2. Nested  repository  references.  They	 are  defined in .hgsub, which
	  should be placed in the root of working directory,  and  tell	 where
	  the subrepository checkouts come from. Mercurial subrepositories are
	  referenced like:

	  path/to/nested = https://example.com/nested/repo/path

	  Git and Subversion subrepos are also supported:

	  path/to/nested = [git]git://example.com/nested/repo/path
	  path/to/nested = [svn]https://example.com/nested/trunk/path

	  where	path/to/nested is the checkout location	relatively to the par-
	  ent  Mercurial root, and https://example.com/nested/repo/path	is the
	  source repository path. The source can also reference	 a  filesystem
	  path.

	  Note	that  .hgsub  does not exist by	default	in Mercurial reposito-
	  ries,	you have to create and add it to the parent repository	before
	  using	subrepositories.

       3. Nested  repository states. They are defined in .hgsubstate, which is
	  placed in the	root of	working	directory, and capture whatever	infor-
	  mation  is required to restore the subrepositories to	the state they
	  were committed in a parent repository	changeset. Mercurial automati-
	  cally	 record	 the nested repositories states	when committing	in the
	  parent repository.

       Note
	  The .hgsubstate file should not be edited manually.

   Adding a Subrepository
       If .hgsub does not exist, create	it and add it to  the  parent  reposi-
       tory. Clone or checkout the external projects where you want it to live
       in the parent repository. Edit .hgsub and add the  subrepository	 entry
       as described above. At this point, the subrepository is tracked and the
       next commit will	record its state in .hgsubstate	and  bind  it  to  the
       committed changeset.

   Synchronizing a Subrepository
       Subrepos	 do  not  automatically	 track	the  latest changeset of their
       sources.	Instead, they are updated to the  changeset  that  corresponds
       with  the  changeset checked out	in the top-level changeset. This is so
       developers always get a consistent set of compatible code and libraries
       when they update.

       Thus,  updating	subrepos  is a manual process. Simply check out	target
       subrepo at the desired revision,	test in	the top-level repo, then  com-
       mit in the parent repository to record the new combination.

   Deleting a Subrepository
       To remove a subrepository from the parent repository, delete its	refer-
       ence from .hgsub, then remove its files.

   Interaction with Mercurial Commands
       add    add does not recurse in subrepos unless -S/--subrepos is	speci-
	      fied.  However, if you specify the full path of a	file in	a sub-
	      repo, it will be added  even  without  -S/--subrepos  specified.
	      Subversion subrepositories are currently silently	ignored.

       addremove
	      addremove	does not recurse into subrepos unless -S/--subrepos is
	      specified.  However, if you specify the full path	of a directory
	      in  a  subrepo,  addremove  will be performed on it even without
	      -S/--subrepos being specified.  Git and Subversion  subreposito-
	      ries will	print a	warning	and continue.

       archive
	      archive does not recurse in subrepositories unless -S/--subrepos
	      is specified.

       cat    Git subrepositories only support exact file matches.  Subversion
	      subrepositories are currently ignored.

       commit commit  creates a	consistent snapshot of the state of the	entire
	      project and its subrepositories.	If  any	 subrepositories  have
	      been  modified,  Mercurial will abort.  Mercurial	can be made to
	      instead  commit  all  modified  subrepositories  by   specifying
	      -S/--subrepos, or	setting	"ui.commitsubrepos=True" in a configu-
	      ration file (see hg help config).	 After there are no longer any
	      modified	subrepositories,  it  records  their state and finally
	      commits it in the	parent	repository.   The  --addremove	option
	      also  honors the -S/--subrepos option.  However, Git and Subver-
	      sion subrepositories will	print a	warning	and abort.

       diff   diff does	not recurse in subrepos	unless -S/--subrepos is	speci-
	      fied.  However, if you specify the full path of a	file or	direc-
	      tory in a	subrepo, it will be diffed even	without	 -S/--subrepos
	      being   specified.   Subversion  subrepositories	are  currently
	      silently ignored.

       files  files does not recurse into  subrepos  unless  -S/--subrepos  is
	      specified.   However,  if	you specify the	full path of a file or
	      directory	in a  subrepo,	it  will  be  displayed	 even  without
	      -S/--subrepos  being specified.  Git and Subversion subreposito-
	      ries are currently silently ignored.

       forget forget currently only handles exact file	matches	 in  subrepos.
	      Git  and	Subversion  subrepositories are	currently silently ig-
	      nored.

       incoming
	      incoming does not	recurse	in subrepos  unless  -S/--subrepos  is
	      specified.  Git  and  Subversion	subrepositories	 are currently
	      silently ignored.

       outgoing
	      outgoing does not	recurse	in subrepos  unless  -S/--subrepos  is
	      specified.  Git  and  Subversion	subrepositories	 are currently
	      silently ignored.

       pull   pull is not recursive since it is	not clear what to  pull	 prior
	      to running hg update. Listing and	retrieving all subrepositories
	      changes referenced by the	parent repository pulled changesets is
	      expensive	at best, impossible in the Subversion case.

       push   Mercurial	will automatically push	all subrepositories first when
	      the parent repository is being pushed.  This  ensures  new  sub-
	      repository  changes  are	available when referenced by top-level
	      repositories.  Push is a no-op for Subversion subrepositories.

       serve  serve does not recurse into subrepositories unless -S/--subrepos
	      is  specified.  Git and Subversion subrepositories are currently
	      silently ignored.

       status status does not recurse into subrepositories unless  -S/--subre-
	      pos is specified.	Subrepository changes are displayed as regular
	      Mercurial	changes	on the subrepository elements. Subversion sub-
	      repositories are currently silently ignored.

       remove remove  does not recurse into subrepositories unless -S/--subre-
	      pos is specified.	 However, if you specify a file	 or  directory
	      path  in	a subrepo, it will be removed even without -S/--subre-
	      pos.  Git	and Subversion subrepositories are currently  silently
	      ignored.

       update update  restores	the subrepos in	the state they were originally
	      committed	in target changeset. If	the recorded changeset is  not
	      available	 in  the current subrepository,	Mercurial will pull it
	      in first before updating.	 This means that updating can  require
	      network access when using	subrepositories.

   Remapping Subrepositories Sources
       A  subrepository	 source	location may change during a project life, in-
       validating references stored in the parent repository history.  To  fix
       this,  rewriting	rules can be defined in	parent repository hgrc file or
       in Mercurial configuration. See the [subpaths] section in  hgrc(5)  for
       more details.

TEMPLATE USAGE
       Mercurial allows	you to customize output	of commands through templates.
       You can either pass in a	template or select an existing	template-style
       from the	command	line, via the --template option.

       You can customize output	for any	"log-like" command: log, outgoing, in-
       coming, tip, parents, and heads.

       Some built-in styles are	packaged with Mercurial. These can  be	listed
       with hg log --template list. Example usage:

       $ hg log	-r1.0::1.1 --template changelog

       A  template  is	a piece	of text, with markup to	invoke variable	expan-
       sion:

       $ hg log	-r1 --template "{node}\n"
       b56ce7b07c52de7d5fd79fb89701ea538af65746

   Keywords
       Strings in curly	braces are called keywords. The	availability  of  key-
       words depends on	the exact context of the templater. These keywords are
       usually available for templating	a log-like command:

       activebookmark
	      String. The active  bookmark,  if	 it  is	 associated  with  the
	      changeset.

       author Alias for	{user}

       bisect String. The changeset bisection status.

       bookmarks
	      List  of	strings.  Any bookmarks	associated with	the changeset.
	      Also sets	'active', the name of the active bookmark.

       branch String. The name of the branch on	which the changeset  was  com-
	      mitted.

       changessincelatesttag
	      Integer. All ancestors not in the	latest tag.

       children
	      List of strings. The children of the changeset.

       date   Date information.	The date when the changeset was	committed.

       desc   String. The text of the changeset	description.

       diffstat
	      String.  Statistics of changes with the following	format:	"modi-
	      fied files: +added/-removed lines"

       extras List of dicts with key, value entries of the 'extras'  field  of
	      this changeset.

       file_adds
	      List of strings. Files added by this changeset.

       file_copies
	      List  of	strings.  Files	 copied	 in  this changeset with their
	      sources.

       file_copies_switch
	      List of strings. Like "file_copies" but displayed	 only  if  the
	      --copied switch is set.

       file_dels
	      List of strings. Files removed by	this changeset.

       file_mods
	      List of strings. Files modified by this changeset.

       files  List  of	strings. All files modified, added, or removed by this
	      changeset.

       graphnode
	      String. The character representing  the  changeset  node	in  an
	      ASCII revision graph.

       graphwidth
	      Integer. The width of the	graph drawn by 'log --graph' or	zero.

       index  Integer. The current iteration of	the loop. (0 indexed)

       latesttag
	      List  of	strings.  The  global tags on the most recent globally
	      tagged ancestor of this changeset.  If no	such tags  exist,  the
	      list consists of the single string "null".

       latesttagdistance
	      Integer. Longest path to the latest tag.

       namespaces
	      Dict of lists. Names attached to this changeset per namespace.

       negrev Integer.	The  repository-local changeset	negative revision num-
	      ber, which counts	in the opposite	direction.

       node   String. The changeset identification hash, as a  40  hexadecimal
	      digit string.

       p1     Changeset.  The changeset's first	parent.	{p1.rev} for the revi-
	      sion number, and {p1.node} for the identification	hash.

       p2     Changeset. The changeset's second	parent.	{p2.rev} for the revi-
	      sion number, and {p2.node} for the identification	hash.

       parents
	      List of strings. The parents of the changeset in "rev:node" for-
	      mat. If the changeset has	only one "natural" parent (the	prede-
	      cessor revision) nothing is shown.

       peerurls
	      A	dictionary of repository locations defined in the [paths] sec-
	      tion of your configuration file.

       phase  String. The changeset phase name.

       reporoot
	      String. The root directory of the	current	repository.

       rev    Integer. The repository-local changeset revision number.

       subrepos
	      List of strings. Updated subrepositories in the changeset.

       tags   List of strings. Any tags	associated with	the changeset.

       termwidth
	      Integer. The width of the	current	terminal.

       user   String. The unmodified author of the changeset.

       verbosity
	      String. The current output verbosity in 'debug', 'quiet',	 'ver-
	      bose', or	''.

       The  "date" keyword does	not produce human-readable output. If you want
       to use a	date in	your output, you can use a filter to process it.  Fil-
       ters  are  functions which return a string based	on the input variable.
       Be sure to use the  stringify  filter  first  when  you're  applying  a
       string-input  filter to a list-like input variable.  You	can also use a
       chain of	filters	to get the desired output:

       $ hg tip	--template "{date|isodate}\n"
       2008-08-21 18:22	+0000

   Filters
       List of filters:

       addbreaks
	      Any text.	Add an XHTML "<br />" tag before the end of every line
	      except the last.

       age    Date.  Returns a human-readable date/time	difference between the
	      given date/time and the current date/time.

       basename
	      Any text.	Treats the text	as a path, and returns the last	compo-
	      nent of the path after splitting by the path separator.  For ex-
	      ample, "foo/bar/baz" becomes "baz" and "foo/bar//" becomes "".

       cbor   Any object. Serializes the object	to CBOR	bytes.

       commondir
	      List of text. Treats each	list item as file name with / as  path
	      separator	and returns the	longest	common directory prefix	shared
	      by all list items.  Returns the empty string if no common	prefix
	      exists.

	      The  list	items are not normalized, i.e. "foo/../bar" is handled
	      as file "bar" in the directory "foo/..". Leading slashes are ig-
	      nored.

	      For  example,  ["foo/bar/baz",  "foo/baz/bar"] becomes "foo" and
	      ["foo/bar", "baz"] becomes "".

       count  List or text. Returns the	length as an integer.

       dirname
	      Any text.	Treats the text	as a path, and strips the last	compo-
	      nent of the path after splitting by the path separator.

       domain Any  text.  Finds	 the first string that looks like an email ad-
	      dress, and extracts just the  domain  component.	Example:  User
	      <user@example.com> becomes example.com.

       email  Any text.	Extracts the first string that looks like an email ad-
	      dress.  Example:	User  <user@example.com>  becomes   user@exam-
	      ple.com.

       emailuser
	      Any text.	Returns	the user portion of an email address.

       escape Any text.	Replaces the special XML/XHTML characters "&", "<" and
	      ">" with XML entities, and filters out NUL characters.

       fill68 Any text.	Wraps the text to fit in 68 columns.

       fill76 Any text.	Wraps the text to fit in 76 columns.

       firstline
	      Any text.	Returns	the first line of text.

       hex    Any text.	Convert	a binary Mercurial node	 identifier  into  its
	      long hexadecimal representation.

       hgdate Date.  Returns the date as a pair	of numbers: "1157407993	25200"
	      (Unix timestamp, timezone	offset).

       isodate
	      Date. Returns the	date in	ISO  8601  format:  "2009-08-18	 13:00
	      +0200".

       isodatesec
	      Date.  Returns  the  date	in ISO 8601 format, including seconds:
	      "2009-08-18 13:00:13 +0200". See also the	rfc3339date filter.

       json   Any object. Serializes the object	to a JSON formatted text.

       lower  Any text.	Converts the text to lowercase.

       nonempty
	      Any text.	Returns	'(none)' if the	string is empty.

       obfuscate
	      Any text.	Returns	the input text rendered	as a sequence  of  XML
	      entities.

       person Any text.	Returns	the name before	an email address, interpreting
	      it as per	RFC 5322.

       revescape
	      Any text.	Escapes	all "special" characters, except  @.   Forward
	      slashes  are  escaped  twice  to prevent web servers from	prema-
	      turely unescaping	them.  For  example,  "@foo  bar/baz"  becomes
	      "@foo%20bar%252Fbaz".

       rfc3339date
	      Date. Returns a date using the Internet date format specified in
	      RFC 3339:	"2009-08-18T13:00:13+02:00".

       rfc822date
	      Date. Returns a date using the same format used in  email	 head-
	      ers: "Tue, 18 Aug	2009 13:00:13 +0200".

       short  Changeset	hash. Returns the short	form of	a changeset hash, i.e.
	      a	12 hexadecimal digit string.

       shortbisect
	      Any text.	Treats label as	a bisection status, and	returns	a sin-
	      gle-character  representing  the	status	(G:  good,  B: bad, S:
	      skipped, U: untested, I: ignored). Returns single	space if  text
	      is not a valid bisection status.

       shortdate
	      Date. Returns a date like	"2006-09-18".

       slashpath
	      Any text.	Replaces the native path separator with	slash.

       splitlines
	      Any text.	Split text into	a list of lines.

       stringify
	      Any  type.  Turns	 the value into	text by	converting values into
	      text and concatenating them.

       stripdir
	      Treat the	text as	path and strip a directory level, if possible.
	      For example, "foo" and "foo/bar" becomes "foo".

       tabindent
	      Any text.	Returns	the text, with every non-empty line except the
	      first starting with a tab	character.

       upper  Any text.	Converts the text to uppercase.

       urlescape
	      Any text.	Escapes	all "special" characters.  For	example,  "foo
	      bar" becomes "foo%20bar".

       user   Any text.	Returns	a short	representation of a user name or email
	      address.

       utf8   Any text.	Converts from the local	character encoding to UTF-8.

       Note that  a  filter  is	 nothing  more	than  a	 function  call,  i.e.
       expr|filter is equivalent to filter(expr).

   Functions
       In addition to filters, there are some basic built-in functions:

       config(section, name[, default])
	      Returns the requested hgrc config	option as a string.

       configbool(section, name[, default])
	      Returns the requested hgrc config	option as a boolean.

       configint(section, name[, default])
	      Returns the requested hgrc config	option as an integer.

       date(date[, fmt])
	      Format a date. See hg help dates for formatting strings. The de-
	      fault is a Unix date format, including the timezone: "Mon	Sep 04
	      15:13:13 2006 0700".

       dict([[key=]value...])
	      Construct	a dict from key-value pairs. A key may be omitted if a
	      value expression can provide an unambiguous name.

       diff([includepattern [, excludepattern]])
	      Show a diff, optionally specifying files to include or exclude.

       files(pattern)
	      All files	of the current changeset matching the pattern. See  hg
	      help patterns.

       fill(text[, width[, initialident[, hangindent]]])
	      Fill  many  paragraphs with optional indentation.	See the	"fill"
	      filter.

       filter(iterable[, expr])
	      Remove empty elements from a list	or a dict. If expr  specified,
	      it's applied to each element to test emptiness.

       get(dict, key)
	      Get  an  attribute/key from an object. Some keywords are complex
	      types. This function allows you to obtain	the value of an	attri-
	      bute on these types.

       if(expr,	then[, else])
	      Conditionally execute based on the result	of an expression.

       ifcontains(needle, haystack, then[, else])
	      Conditionally  execute  based on whether the item	"needle" is in
	      "haystack".

       ifeq(expr1, expr2, then[, else])
	      Conditionally execute based on whether 2 items are equivalent.

       indent(text, indentchars[, firstline])
	      Indents all non-empty lines with the characters given in the in-
	      dentchars	 string. An optional third parameter will override the
	      indent for the first line	only if	present.

       join(list, sep)
	      Join items in a list with	a delimiter.

       label(label, expr)
	      Apply a label to generated content. Content with a label applied
	      can result in additional post-processing,	such as	automatic col-
	      orization.

       latesttag([pattern])
	      The global tags matching the given pattern on  the  most	recent
	      globally tagged ancestor of this changeset.  If no such tags ex-
	      ist, the "{tag}" template	resolves to the	string "null". See  hg
	      help revisions.patterns for the pattern syntax.

       localdate(date[,	tz])
	      Converts a date to the specified timezone.  The default is local
	      date.

       mailmap(author)
	      Return the author, updated according to the  value  set  in  the
	      .mailmap file

       max(iterable)
	      Return the max of	an iterable

       min(iterable)
	      Return the min of	an iterable

       mod(a, b)
	      Calculate	a mod b	such that a / b	+ a mod	b == a

       pad(text, width[, fillchar=' '[,	left=False[, truncate=False]]])
	      Pad text with a fill character.

       relpath(path)
	      Convert  a repository-absolute path into a filesystem path rela-
	      tive to the current working directory.

       revset(query[, formatargs...])
	      Execute a	revision set query. See	hg help	revset.

       rstdoc(text, style)
	      Format reStructuredText.

       search(pattern, text)
	      Look for the first text matching the regular expression pattern.
	      Groups are accessible as {1}, {2}, ... in	%-mapped template.

       separate(sep, args...)
	      Add a separator between non-empty	arguments.

       shortest(node, minlength=4)
	      Obtain the shortest representation of a node.

       startswith(pattern, text)
	      Returns the value	from the "text"	argument if it begins with the
	      content from the "pattern" argument.

       strip(text[, chars])
	      Strip characters from a string. By default, strips  all  leading
	      and trailing whitespace.

       sub(pattern, replacement, expression)
	      Perform text substitution	using regular expressions.

       word(number, text[, separator])
	      Return the nth word from a string.

   Operators
       We provide a limited set	of infix arithmetic operations on integers:

       + for addition
       - for subtraction
       * for multiplication
       / for floor division (division rounded to integer nearest -infinity)

       Division	fulfills the law x = x / y + mod(x, y).

       Also, for any expression	that returns a list, there is a	list operator:

       expr % "{template}"

       As  seen	in the above example, {template} is interpreted	as a template.
       To prevent it from being	interpreted, you can use an  escape  character
       \{ or a raw string prefix, r'...'.

       The dot operator	can be used as a shorthand for accessing a sub item:

       o expr.member  is  roughly  equivalent to expr %	'{member}' if expr re-
	 turns a non-list/dict.	The returned value is not stringified.

       o dict.key is identical to get(dict, 'key').

   Aliases
       New keywords and	functions can be defined in the	templatealias  section
       of a Mercurial configuration file:

       <alias> = <definition>

       Arguments  of the form a1, a2, etc. are substituted from	the alias into
       the definition.

       For example,

       [templatealias]
       r = rev
       rn = "{r}:{node|short}"
       leftpad(s, w) = pad(s, w, ' ', True)

       defines two symbol aliases, r and rn, and a function alias leftpad().

       It's also possible to specify complete template strings,	using the tem-
       plates section. The syntax used is the general template string syntax.

       For example,

       [templates]
       nodedate	= "{node|short}: {date(date, "%Y-%m-%d")}\n"

       defines a template, nodedate, which can be called like:

       $ hg log	-r . -Tnodedate

       A template defined in templates section can also	be referenced from an-
       other 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:

       o Format	lists, e.g. files:

	 $ hg log -r 0 --template "files:\n{files % '  {file}\n'}"

       o Join the list of files	with a ", ":

	 $ hg log -r 0 --template "files: {join(files, ', ')}\n"

       o Join the list of files	ending with ".py" with a ", ":

	 $ hg log -r 0 --template "pythonfiles:	{join(files('**.py'), ', ')}\n"

       o Separate non-empty arguments by a " ":

	 $ hg log -r 0 --template "{separate(' ', node,	bookmarks, tags}\n"

       o Modify	each line of a commit description:

	 $ hg log --template "{splitlines(desc)	% '****	{line}\n'}"

       o Format	date:

	 $ hg log -r 0 --template "{date(date, '%Y')}\n"

       o Display date in UTC:

	 $ hg log -r 0 --template "{localdate(date, 'UTC')|date}\n"

       o Output	the description	set to a fill-width of 30:

	 $ hg log -r 0 --template "{fill(desc, 30)}"

       o 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"

       o Append	a newline if not empty:

	 $ hg tip --template "{if(author, '{author}\n')}"

       o Label the output for use with the color extension:

	 $ hg log -r 0 --template "{label('changeset.{phase}', node|short)}\n"

       o Invert	the firstline filter, i.e. everything but the first line:

	 $ hg log -r 0 --template "{sub(r'^.*\n?\n?', '', desc)}\n"

       o Display the contents of the 'extra' field, one	per line:

	 $ hg log -r 0 --template "{join(extras, '\n')}\n"

       o Mark the active bookmark with '*':

	 $ hg log --template "{bookmarks % '{bookmark}{ifeq(bookmark, active, '*')} '}\n"

       o Find  the  previous  release  candidate tag, the distance and changes
	 since the tag:

	 $ hg log -r . --template "{latesttag('re:^.*-rc$') % '{tag}, {changes}, {distance}'}\n"

       o Mark the working copy parent with '@':

	 $ hg log --template "{ifcontains(rev, revset('.'), '@')}\n"

       o Show details of parent	revisions:

	 $ hg log --template "{revset('parents(%d)', rev) % '{desc|firstline}\n'}"

       o Show only commit descriptions that start with "template":

	 $ hg log --template "{startswith('template', firstline(desc))}\n"

       o Print the first word of each line of a	commit message:

	 $ hg log --template "{word(0, desc)}\n"

URL PATHS
       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]

       Paths in	the local filesystem can either	point to  Mercurial  reposito-
       ries  or	to bundle files	(as created by hg bundle or hg incoming	--bun-
       dle). 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:

       o SSH  requires	an accessible shell account on the destination machine
	 and a copy of hg in the remote	path or	specified with remotecmd.

       o 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

       o 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 configura-
	 tion 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 reposi-
	      tory'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.

EXTENSIONS
       This section contains help for extensions that are distributed together
       with Mercurial. Help for	other extensions is available in the help sys-
       tem.

   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 confir-
       mation.	 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.

       Options:

       -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 (EXPERIMENTAL)

       -e, --edit-lines
	      edit what	lines belong to	which changesets before	commit (EXPER-
	      IMENTAL)

       -n, --dry-run
	      do not perform actions, just print output

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   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, pre-
       venting 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:

       o a branch name,	or

       o an asterisk, to match any branch;

       The corresponding values	can be either:

       o a comma-separated list	containing users and groups, or

       o 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  con-
       trol. Keys in these sections accept a subtree pattern (with a glob syn-
       tax 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:

       o a bookmark name, or

       o an asterisk, to match any bookmark;

       The corresponding values	can be either:

       o a comma-separated list	containing users and groups, or

       o an asterisk, to match anyone;

       You can add the "!" prefix to a user or group name to invert the	 sense
       of the match.

       Note: for interactions between clients and servers using	Mercurial 3.6+
       a rejection will	generally reject the entire push, for interactions in-
       volving	older  clients,	 the  commit  transactions will	already	be ac-
       cepted, 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 ex-
       ception 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 any-
       one 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

       [acl.deny.branches]

       # 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  in-
       voking editor, unless --edit was	set.

       See hg help commit for more details.

       Options:

       -A, --addremove
	      mark new/missing files as	added/removed before committing

       -e, --edit
	      invoke editor on commit messages

       -i, --interactive
	      use interactive mode

       -n,--note <VALUE>
	      store a note on the amend

       -D, --currentdate
	      record the current date as commit	date

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       [+] marked option can be	specified multiple times

   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  re-
	  quired.

   blackbox
       log repository events to	a blackbox for debugging

       Logs  event  information	to .hg/blackbox.log to help debug and diagnose
       problems.  The events that get logged can be configured via the	black-
       box.track and blackbox.ignore config keys.

       Examples:

       [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

       Options:

       -l,--limit <VALUE>
	      the number of events to show (default: 10)

   bookflow
       implements bookmark-based branching (EXPERIMENTAL)

	  o Disables creation of new branches (config: enable_branches=False).

	  o Requires  an  active  bookmark  on	commit	(config: require_book-
	    mark=True).

	  o Doesn't move the active bookmark on	update,	only on	commit.

	  o Requires '--rev' for moving	an existing bookmark.

	  o 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

   bugzilla
       hooks for integrating with the Bugzilla bug tracker

       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  installa-
	  tions	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 pass-
       word 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	speci-
       fied 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:

	      restapi

		     Bugzilla REST-API,	Bugzilla 5.0 and later.

	      xmlrpc

		     Bugzilla XMLRPC interface.

	      xmlrpc+email

		     Bugzilla XMLRPC and email interfaces.

	      3.0

		     MySQL access, Bugzilla 3.0	and later.

	      2.18

		     MySQL  access,  Bugzilla 2.18 and up to but not including
		     3.0.

	      2.16

		     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 com-
	      mit message.  It must contain one	"()" named  group  <ids>  con-
	      taining  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	insen-
	      sitive.

       bugzilla.fixregexp
	      Regular expression to match bug IDs for marking fixed in change-
	      set 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  num-
	      ber  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 pre-
	      fixed by h or hours, e.g.	hours 1.5. Matching is	case  insensi-
	      tive.

       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 ex-
	      tension 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  pro-
	      duce  {webroot}.	For example, a repository with {root} /var/lo-
	      cal/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  commit-
       ter  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://lo-
	      calhost/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.  De-
	      fault 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 change-
	      set 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 notifica-
	      tion emails. Substitutes from a map with 3 keys, bzdir, id  (bug
	      id) and user (committer bugzilla email). Default depends on ver-
	      sion; from 2.18 it is "cd	%(bzdir)s && perl -T  contrib/sendbug-
	      mail.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	  bug-
       mail@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	  bug-
       mail@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

       [web]
       baseurl=http://my-project.org/hg

       [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

       [web]
       baseurl=http://my-project.org/hg

       [usermap]
       user@emaildomain.com=user.name@bugzilladomain.com

       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.

   censor
       erase file content at a given revision

       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,  in-
       cluding:

       * 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=ig-
       nore" config option.

   Commands
   Repository maintenance
   censor
       hg censor -r REV	[-t TEXT] [FILE]

       Options:

       -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.

       Options:

       -r,--rev	<REV>
	      show children of the specified revision (default:	.)

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

   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	speci-
       fied.

       Examples:

       # 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

       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	"=".

       Options:

       -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

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   clonebundles
       advertise pre-generated bundles to seed clones

       "clonebundles" is a server-side extension used to advertise  the	 exis-
       tence  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	opera-
       tions.

       Cloning can be a	CPU and	I/O intensive operation	on servers. Tradition-
       ally, the server, in response to	a client's request to  clone,  dynami-
       cally  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	poten-
       tially  expensive clone load to an external service. Pre-generated bun-
       dles also allow using more CPU intensive	compression, reducing the  ef-
       fective 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	equiv-
	  alent	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	"pull-
	  bundles".

       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	 revi-
	  sions	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 advertis-
	  ing partial pulls, it	checks for a matching pull bundle in the mani-
	  fest.	 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:

       o Generating bundle files of  repository	 content  (typically  periodi-
	 cally,	such as	once per day).

       o Clone	bundles: A file	server that clients have network access	to and
	 that Python knows how to talk to through its normal URL handling  fa-
	 cility	(typically an HTTP/HTTPS server).

       o 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 effi-
       cient 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 ver-
       sions of	Mercurial may produce  streaming  clone	 bundles  incompatible
       with older Mercurial versions.

       A  server operator is responsible for creating a	.hg/clonebundles.mani-
       fest 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 for-
       mat:

	  <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 be-
       low.  All non-uppercase keys can	be used	by site	installations. An  ex-
       ample  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"	 argu-
	      ment of hg bundle.

	      The  values  are parsed in strict	mode, which means they must be
	      of   the	 "<compression>-<type>"	  form.	  See	 mercurial.ex-
	      change.parsebundlespec() for more	details.

	      hg debugbundle --spec can	be used	to print the bundle specifica-
	      tion string for a	bundle file. The output	of this	command	can be
	      used  verbatim  for  the	value of BUNDLESPEC (it	is already es-
	      caped).

	      Clients will automatically filter	out  specifications  that  are
	      unknown  or  unsupported so they won't attempt to	download some-
	      thing that likely	won't apply.

	      The actual value doesn't impact client behavior  beyond  filter-
	      ing: 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 fall-
	      back URL or clients running old Python releases may not be  able
	      to clone with the	clonebundles facility.

	      Value should be "true".

       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 rea-
       son 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  an-
       other service and that the Mercurial server isn't responsible for serv-
       ing 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 pre-
       pare  for  some	people to follow these instructions when a failure oc-
       curs, thus driving more load to the original Mercurial server when  the
       bundle hosting service fails.

   closehead
       close arbitrary heads without checking them out first

   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.

       Options:

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -r,--rev	<REV[+]>
	      revision to check

       [+] marked option can be	specified multiple times

	  aliases: close-heads

   commitextras
       adds a new flag extras to commit	(ADVANCED)

   convert
       import revisions	from foreign VCS repositories into Mercurial

   Commands
   Uncategorized commands
   convert
       convert a foreign SCM repository	to a Mercurial one.:

       hg convert [OPTION]... SOURCE [DEST [REVMAP]]

       Accepted	source formats [identifiers]:

       o Mercurial [hg]

       o CVS [cvs]

       o Darcs [darcs]

       o git [git]

       o Subversion [svn]

       o Monotone [mtn]

       o GNU Arch [gnuarch]

       o Bazaar	[bzr]

       o Perforce [p4]

       Accepted	destination formats [identifiers]:

       o Mercurial [hg]

       o 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 base-
       name 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.	Mercu-
       rial 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	Mercu-
	      rial 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 re-
       peatedly	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  map-
       ping 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 in-
       clude 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  discon-
       nected  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	 revi-
       sion  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 con-
       junction	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 des-
       tination	 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 in-
       dicate  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	 reor-
       ganization 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 de-
	      bugging 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 change-
	      set. When	very large files were checked in as part of a  change-
	      set 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 mes-
	      sages. 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 ex-
	      ecuted 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 in-
	      sert  a dummy revision merging the branch	on which this log mes-
	      sage 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 change-
       set 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.

       convert.localtimezone
	      use  local  time	(as determined by the TZ environment variable)
	      for changeset date/times.	The default is False (use UTC).

       Source history can be retrieved starting	at a  specific	revision,  in-
       stead 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.

       The following options can be set	with --config:

       convert.git.similarity
	      specify how similar files	modified in a commit must be to	be im-
	      ported  as  renames  or  copies, as a percentage between 0 (dis-
	      abled) 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.simi-
	      larity 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 com-
	      mitter  (who  applied  the  commit) fields. Not all destinations
	      support separate author and committer fields  (including	Mercu-
	      rial).  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  syn-
	      tax messagedifferent=<prefix>. e.g. messagedifferent=git-commit-
	      ter:.  When a prefix is specified, a space will  always  be  in-
	      serted between the prefix	and the	value.

	      messagealways  behaves  like messagedifferent except it will al-
	      ways result in a committer: ... line being appended to the  com-
	      mit  message.  This value	is mutually exclusive with messagedif-
	      ferent.

	      dropcommitter will remove	references to the committer. Only ref-
	      erences  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 commit-
	      ter 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  destina-
	      tion. Some Git repositories store	extra metadata in commits.  By
	      default, this non-default	metadata will be lost  during  conver-
	      sion.  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.re-
	      moteprefix 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.

       The following options can be set	with --config:

       convert.p4.encoding
	      specify the encoding to use when decoding	standard output	of the
	      Perforce command line tool. The default is default system	encod-
	      ing.

       convert.p4.startrev
	      specify initial Perforce revision	(a  Perforce  changelist  num-
	      ber).

   Mercurial Destination
       The  Mercurial  destination will	recognize Mercurial subrepositories in
       the destination directory, and update the  .hgsubstate  file  automati-
       cally	 if    the    destination    subrepositories	contain	   the
       <dest>/<sub>/.hg/shamap file.  Converting a repository with  subreposi-
       tories requires converting a single repository at a time, from the bot-
       tom 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

       The following options are supported:

       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  perfor-
	      mance  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.

       Options:

       --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

       [+] marked option can be	specified multiple times

   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 configu-
       ration 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	speci-
       fied 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:

       o 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.

       o 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.

       o 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.check-
       headshook  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.

   extdiff
       command to allow	external programs to compare revisions

       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  op-
       tions "-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.

       When  two  revision arguments are given,	then changes are shown between
       those revisions.	If only	one revision is	specified then	that  revision
       is compared to the working directory, and, when no revisions are	speci-
       fied, the working directory files are compared to its parent.

       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  pro-
       gram 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.

       Options:

       -p,--program <CMD>
	      comparison program to run

       -o,--option <OPT[+]>
	      pass option to comparison	program

       -r,--rev	<REV[+]>
	      revision

       -c,--change <REV>
	      change made by revision

       --per-file
	      compare each file	instead	of revision snapshots

       --confirm
	      prompt user before each external program invocation

       --patch
	      compare patches for two revisions

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

   factotum
       http authentication with	factotum

       This extension allows the factotum(4) facility on Plan 9	from Bell Labs
       platforms  to  provide authentication information for HTTP access. Con-
       figuration entries specified in the auth	section	as well	as authentica-
       tion 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 "debug-
       buildannotatecache".

       [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

       # use flock instead of the file existence lock
       # flock may not work well on some network filesystems, but they avoid
       # creating and deleting files frequently, which is faster when updating
       # the annotate cache in batch. if you have issues with this option, set it
       # to False. (default: True if flock is supported, False otherwise)
       useflock	= True

       # 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
   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 work-
       ing 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.

       See hg help dates for a list of formats valid for -d/--date.

       Returns 0 on success.

       Options:

       -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

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   fix
       rewrite file content in changesets or working copy (EXPERIMENTAL)

       Provides	a command that runs configured tools on	the contents of	 modi-
       fied  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	 stan-
       dard  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

       The :pattern suboption determines which files will  be  passed  through
       each  configured	 tool.	See  hg	 help patterns for possible values. 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 de-
       scending	 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 in-
       cremental formatting are	recomputed before executing the	next tool. So,
       each tool may see different values for the arguments added by the :lin-
       erange 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 en-
       coding 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
	 valueof 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.

   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 revisions are	specified with --rev, those revisions will be checked,
       and  they  may be replaced with new revisions that have fixed file con-
       tent.  It is desirable to specify all descendants of each specified re-
       vision,	so that	the fixes propagate to the descendants.	If all descen-
       dants are fixed at the same time, no merging,  rebasing,	 or  evolution
       will be required.

       If --working-dir	is used, files with uncommitted	changes	in the working
       copy will be fixed. If the checked-out  revision	 is  also  fixed,  the
       working directory will update to	the replacement	revision.

       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 ear-
       lier  revisions are not forgotten in later ones.	The --base flag	can be
       used to override	this default behavior, though it is not	usually	desir-
       able to do so.

       Options:

       --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

       -w, --working-dir
	      fix the working directory

       --whole
	      always fix every line of a file

       [+] marked option can be	specified multiple times

   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	recom-
       mended 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)

       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.

   githelp
       try mapping git commands	to Mercurial commands

       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.

       See hg help dates for a list of formats valid for -d/--date.

       Options:

       -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

       -m,--message <TEXT>
	      use text as commit message

       -e, --edit
	      invoke editor on commit messages

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

   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.

       Options:

       -f, --follow
	      follow  changeset	history, or file history across	copies and re-
	      names

       --follow-first
	      only follow the first parent of merge changesets (DEPRECATED)

       -d,--date <DATE>
	      show revisions matching date spec

       -C, --copies
	      show copied files

       -k,--keyword <TEXT[+]>
	      do case-insensitive search for a given text

       -r,--rev	<REV[+]>
	      show the specified revision or revset

       --removed
	      include revisions	where files were removed

       -m, --only-merges
	      show only	merges (DEPRECATED)

       -u,--user <USER[+]>
	      revisions	committed by user

       --only-branch _BRANCH[+]_
	      show only	changesets within the given named branch (DEPRECATED)

       -b,--branch <BRANCH[+]>
	      show changesets within the given named branch

       -P,--prune <REV[+]>
	      do not display revision or any of	its ancestors

       -p, --patch
	      show patch

       -g, --git
	      use git extended diff format

       -l,--limit <NUM>
	      limit number of changes displayed

       -M, --no-merges
	      do not show merges

       --stat output diffstat-style summary of changes

       -G, --graph
	      show the revision	DAG

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   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	repos-
       itory, 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.   As-
       suming you had already configured extdiff vdiff command,	just add:

       [hgk]
       vdiff=vdiff

       Revisions  context menu will now	display	additional entries to fire vd-
       iff on hovered and selected revisions.

   Commands
   Change navigation
   view
       start interactive history viewer:

       hg view [-l LIMIT] [REVRANGE]

       start interactive history viewer

       Options:

       -l,--limit <NUM>
	      limit number of changes displayed

   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.

   histedit
       interactive history editing

       With  this extension installed, Mercurial gains one new command:	histe-
       dit. 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  follow-
       ing 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 stop for amending
       #  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 re-
       vision as beta, you would reorganize the	file to	look like this:

       pick 030b686bedc4 Add gamma
       pick c561b4e977df Add beta
       fold 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 stop for amending
       #  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
       #

       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	tempo-
       rary 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 depend-
       ing  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 immedi-
       ately followed by hg histedit --continue`.

       If histedit encounters a	conflict when moving a	revision  (while  han-
       dling  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	histe-
       dit  --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 reposi-
       tory  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 configu-
       ration 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 cus-
       tomization.

       hg histedit attempts to automatically choose an appropriate base	 revi-
       sion  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  com-
       mands.  To remove revision you need to use drop operation. You can con-
       figure 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	trans-
       action 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 in-
       cluding the working directory, which should be clean).  You can:

       o pick to [re]order a changeset

       o drop to omit changeset

       o mess to reword	the changeset commit message

       o fold  to  combine  it	with  the preceding changeset (using the later
	 date)

       o roll like fold, but discarding	this commit's description and date

       o edit to edit this changeset (preserving date)

       o base to checkout changeset and	apply further changesets from there

       There are a number of ways to select the	root changeset:

       o Specify ANCESTOR directly

       o Use --outgoing	-- it will be the first	linear changeset not  included
	 in destination. (See hg help config.paths.default-push)

       o 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 de-
	 fault,	this selects the editable history that is unique to the	ances-
	 try 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  con-
       taining 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.

       Examples:

	  o 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	begin-
	    ning 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

	  o 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

	    An editor opens, containing	the list of revisions,	with  specific
	    actions specified:

	    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  con-
       flicts).

       Options:

       --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

       -T,--template <TEMPLATE>
	      display with template

       [+] marked option can be	specified multiple times

   infinitepush
	  store	 some  pushes in a remote blob store on	the server (EXPERIMEN-
	  TAL)

	      [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  bun-
	      dle 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} {han-
	      dle} 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 re-
	      mote 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 posi-
       tions 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 reg-
       ular 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.

       Options:

       --all  show history for all names

       -c, --commits
	      show commit metadata

       -p, --patch
	      show patch

       -g, --git
	      use git extended diff format

       -l,--limit <NUM>
	      limit number of changes displayed

       --stat output diffstat-style summary of changes

       --style _STYLE_
	      display using template map file (DEPRECATED)

       -T,--template <TEMPLATE>
	      display with template

   keyword
       expand keywords in tracked files

       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.

       Example:

       [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 con-
       trol run	hg kwdemo. See hg help templates for a list of available  tem-
       plates 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	expan-
       sions.

       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.

       See hg help templates for information on	templates and filters.

       Options:

       -d, --default
	      show default keyword template maps

       -f,--rcfile <FILE>
	      read maps	from rcfile

   kwexpand
       expand keywords in the working directory:

       hg kwexpand [OPTION]... [FILE]...

       Run after (re)enabling keyword expansion.

       kwexpand	refuses	to run if given	files contain local changes.

       Options:

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   kwfiles
       show files configured for keyword expansion:

       hg kwfiles [OPTION]... [FILE]...

       List  which files in the	working	directory are matched by the [keyword]
       configuration patterns.

       Useful to prevent inadvertent keyword expansion and to speed up	execu-
       tion by including only files that are actual candidates for expansion.

       See hg help keyword on how to construct patterns	both for inclusion and
       exclusion of files.

       With -A/--all and -v/--verbose the codes	used to	 show  the  status  of
       files are:

       K = keyword expansion candidate
       k = keyword expansion candidate (not tracked)
       I = ignored
       i = ignored (not	tracked)

       Options:

       -A, --all
	      show keyword status flags	of all files

       -i, --ignore
	      show files excluded from expansion

       -u, --unknown
	      only show	unknown	(not tracked) files

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   kwshrink
       revert expanded keywords	in the working directory:

       hg kwshrink [OPTION]... [FILE]...

       Must be run before changing/disabling active keywords.

       kwshrink	refuses	to run if given	files contain local changes.

       Options:

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   largefiles
       track large binary files

       Large binary files tend to be not very compressible, not	very diffable,
       and not at all mergeable. Such files are	 not  handled  efficiently  by
       Mercurial's  storage  format (revlog), which is based on	compressed bi-
       nary deltas; storing large binary  files	 as  regular  Mercurial	 files
       wastes bandwidth	and disk space and increases Mercurial's memory	usage.
       The largefiles extension	addresses these	problems by adding a  central-
       ized client-server layer	on top of Mercurial: largefiles	live in	a cen-
       tral store out on the network somewhere,	and you	only fetch  the	 revi-
       sions that you need when	you need them.

       largefiles  works  by  maintaining  a "standin file" in .hglf/ for each
       largefile. The standins are small (41 bytes: an SHA-1  hash  plus  new-
       line)  and are tracked by Mercurial. Largefile revisions	are identified
       by the SHA-1 hash of their contents, which is written to	 the  standin.
       largefiles uses that revision ID	to get/put largefile revisions from/to
       the central store. This saves both disk space and bandwidth, since  you
       don't need to retrieve all historical revisions of large	files when you
       clone or	pull.

       To start	a new repository or add	 new  large  binary  files,  just  add
       --large to your hg add command. For example:

       $ dd if=/dev/urandom of=randomdata count=2000
       $ hg add	--large	randomdata
       $ hg commit -m "add randomdata as a largefile"

       When  you  push	a  changeset that adds/modifies	largefiles to a	remote
       repository, its largefile revisions will	be  uploaded  along  with  it.
       Note  that the remote Mercurial must also have the largefiles extension
       enabled for this	to work.

       When you	pull a changeset that affects largefiles from a	remote reposi-
       tory,  the  largefiles  for the changeset will by default not be	pulled
       down. However, when you update  to  such	 a  revision,  any  largefiles
       needed  by  that	revision are downloaded	and cached (if they have never
       been downloaded before).	One way	to pull	 largefiles  when  pulling  is
       thus to use --update, which will	update your working copy to the	latest
       pulled revision (and thereby downloading	any new	largefiles).

       If you want to pull largefiles you don't	need for update	yet, then  you
       can use pull with the --lfrev option or the hg lfpull command.

       If  you	know  you  are pulling from a non-default location and want to
       download	all the	largefiles that	correspond to the  new	changesets  at
       the same	time, then you can pull	with --lfrev "pulled()".

       If  you just want to ensure that	you will have the largefiles needed to
       merge or	rebase with new	heads that you are pulling, then you can  pull
       with --lfrev "head(pulled())" flag to pre-emptively download any	large-
       files that are new in the heads you are pulling.

       Keep in mind that network access	may  now  be  required	to  update  to
       changesets  that	 you have not previously updated to. The nature	of the
       largefiles extension means that updating	is no longer guaranteed	to  be
       a local-only operation.

       If you already have large files tracked by Mercurial without the	large-
       files extension,	you will need to convert your repository in  order  to
       benefit from largefiles.	This is	done with the hg lfconvert command:

       $ hg lfconvert --size 10	oldrepo	newrepo

       In repositories that already have largefiles in them, any new file over
       10MB will automatically be added	as a largefile.	To change this thresh-
       old,  set largefiles.minsize in your Mercurial config file to the mini-
       mum size	in megabytes to	track as a largefile, or use the --lfsize  op-
       tion to the add command (also in	megabytes):

       [largefiles]
       minsize = 2

       $ hg add	--lfsize 2

       The  largefiles.patterns	 config	option allows you to specify a list of
       filename	patterns (see hg help patterns)	that should always be  tracked
       as largefiles:

       [largefiles]
       patterns	=
	 *.jpg
	 re:.*\.(png|bmp)$
	 library.zip
	 content/audio/*

       Files  that match one of	these patterns will be added as	largefiles re-
       gardless	of their size.

       The largefiles.minsize and largefiles.patterns config options  will  be
       ignored for any repositories not	already	containing a largefile.	To add
       the first largefile to a	repository, you	must explicitly	do so with the
       --large flag passed to the hg add command.

   Commands
   Uncategorized commands
   lfconvert
       convert a normal	repository to a	largefiles repository:

       hg lfconvert SOURCE DEST	[FILE ...]

       Convert repository SOURCE to a new repository DEST, identical to	SOURCE
       except that certain files will be  converted  as	 largefiles:  specifi-
       cally,  any  file  that	matches	any PATTERN or whose size is above the
       minimum size threshold is converted as a	largefile. The	size  used  to
       determine  whether or not to track a file as a largefile	is the size of
       the first version of the	file. The minimum size can be specified	either
       with --size or in configuration as largefiles.size.

       After  running  this command you	will need to make sure that largefiles
       is enabled anywhere you intend to push the new repository.

       Use --to-normal to convert largefiles back to normal files; after this,
       the DEST	repository can be used without largefiles at all.

       Options:

       -s,--size <SIZE>
	      minimum size (MB)	for files to be	converted as largefiles

       --to-normal
	      convert from a largefiles	repo to	a normal repo

   lfpull
       pull largefiles for the specified revisions from	the specified source:

       hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [SOURCE]

       Pull  largefiles	 that are referenced from local	changesets but missing
       locally,	pulling	from a remote repository to the	local cache.

       If SOURCE is omitted, the 'default' path	will be	 used.	 See  hg  help
       urls for	more information.

       Some examples:

       o pull largefiles for all branch	heads:

	 hg lfpull -r "head() and not closed()"

       o pull largefiles on the	default	branch:

	 hg lfpull -r "branch(default)"

       Options:

       -r,--rev	<VALUE[+]>
	      pull largefiles for these	revisions

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   lfs
       lfs - large file	support	(EXPERIMENTAL)

       This  extension	allows large files to be tracked outside of the	normal
       repository storage and stored on	a centralized server, similar  to  the
       largefiles  extension.  The git-lfs protocol is used when communicating
       with the	server,	so existing git	infrastructure can be harnessed.  Even
       though  the  files are stored outside of	the repository,	they are still
       integrity checked in the	same manner as normal files.

       The files stored	outside	of the repository are  downloaded  on  demand,
       which  reduces  the  time  to clone, and	possibly the local disk	usage.
       This changes fundamental	workflows in a DVCS, so	careful	thought	should
       be  given  before  deploying it.	 hg convert can	be used	to convert LFS
       repositories to normal repositories that	no longer require this	exten-
       sion,  and  do  so without changing the commit hashes.  This allows the
       extension to be disabled	if the centralized  workflow  becomes  burden-
       some.   However,	 the  pre  and post convert clones will	not be able to
       communicate with	each other unless the extension	is enabled on both.

       To start	a new repository, or to	add LFS	files to an existing one, just
       create  an  .hglfs file as described below in the root directory	of the
       repository.  Typically, this file should	be put under version  control,
       so that the settings will propagate to other repositories with push and
       pull.  During any commit, Mercurial will	consult	this file to determine
       if  an added or modified	file should be stored externally.  The type of
       storage depends on the characteristics of the file at each  commit.   A
       file  that  is  near a size threshold may switch	back and forth between
       LFS and normal storage, as needed.

       Alternately, both normal	repositories and largefile controlled  reposi-
       tories  can  be	converted to LFS by using hg convert and the lfs.track
       config option described below.  The .hglfs file should then be  created
       and  added,  to	control	subsequent LFS selection.  The hashes are also
       unchanged in this case.	The LFS	and non-LFS repositories can  be  dis-
       tinguished  because  the	 LFS repository	will abort any command if this
       extension is disabled.

       Committed LFS files are held locally, until the repository  is  pushed.
       Prior  to  pushing  the	normal repository data,	the LFS	files that are
       tracked by the outgoing commits are automatically uploaded to the  con-
       figured	central	server.	 No LFS	files are transferred on hg pull or hg
       clone.  Instead,	the files are downloaded on demand as they need	to  be
       read,  if  a  cached copy cannot	be found locally.  Both	committing and
       downloading an LFS file will link the file to a usercache, to speed  up
       future access.  See the usercache config	setting	described below.

       The extension reads its configuration from a versioned ``.hglfs``
       configuration file found	in the root of the working directory. The
       ``.hglfs`` file uses the	same syntax as all other Mercurial
       configuration files. It uses a single section, ``[track]``.

       The ``[track]`` section specifies which files are stored	as LFS (or
       not). Each line is keyed	by a file pattern, with	a predicate value.
       The first file pattern match is used, so	put more specific patterns
       first.  The available predicates	are ``all()``, ``none()``, and
       ``size()``. See "hg help	filesets.size" for the latter.

       Example versioned ``.hglfs`` file::

	 [track]
	 # No Makefile or python file, anywhere, will be LFS
	 **Makefile = none()
	 **.py = none()

	 **.zip	= all()
	 **.exe	= size(">1MB")

	 # Catchall for	everything not matched above
	 ** = size(">10MB")

       Configs:

       [lfs]
       # Remote	endpoint. Multiple protocols are supported:
       # - http(s)://user:pass@example.com/path
       #   git-lfs endpoint
       # - file:///tmp/path
       #   local filesystem, usually for testing
       # if unset, lfs will assume the remote repository also handles blob storage
       # for http(s) URLs.  Otherwise, lfs will	prompt to set this when	it must
       # use this value.
       # (default: unset)
       url = https://example.com/repo.git/info/lfs

       # Which files to	track in LFS.  Path tests are "**.extname" for file
       # extensions, and "path:under/some/directory" for path prefix.  Both
       # are relative to the repository	root.
       # File size can be tested with the "size()" fileset, and	tests can be
       # joined	with fileset operators.	 (See "hg help filesets.operators".)
       #
       # Some examples:
       # - all()		       # everything
       # - none()		       # nothing
       # - size(">20MB")	       # larger	than 20MB
       # - !**.txt		       # anything not a	*.txt file
       # - **.zip | **.tar.gz |	**.7z  # some types of compressed files
       # - path:bin		       # files under "bin" in the project root
       # - (**.php & size(">2MB")) | (**.js & size(">5MB")) | **.tar.gz
       #     | (path:bin & !path:/bin/README) |	size(">1GB")
       # (default: none())
       #
       # This is ignored if there is a tracked '.hglfs'	file, and this setting
       # will eventually be deprecated and removed.
       track = size(">10M")

       # how many times	to retry before	giving up on transferring an object
       retry = 5

       # the local directory to	store lfs files	for sharing across local clones.
       # If not	set, the cache is located in an	OS specific cache location.
       usercache = /path/to/global/cache

   Commands
   Uncategorized commands
   logtoprocess
       send ui.log() data to a subprocess (EXPERIMENTAL)

       This  extension	lets  you  specify a shell command per ui.log()	event,
       sending all remaining arguments to as  environment  variables  to  that
       command.

       Positional  arguments  construct	 a log message,	which is passed	in the
       MSG1 environment	variables. Each	keyword	argument is set	as  a  OPT_UP-
       PERCASE_KEY  variable  (so  the	key  is	 uppercased, and prefixed with
       OPT_). The original event name is passed	in the EVENT environment vari-
       able, and the process ID	of mercurial is	given in HGPID.

       So  given a call	ui.log('foo', 'bar %s ', 'baz',	spam='eggs'), a	script
       configured for the `foo event can expect	an environment	with  MSG1=bar
       baz, and	OPT_SPAM=eggs.

       Scripts are configured in the [logtoprocess] section, each key an event
       name.  For example:

       [logtoprocess]
       commandexception	= echo "$MSG1" > /var/log/mercurial_exceptions.log

       would log the warning message and traceback of any failed command  dis-
       patch.

       Scripts	are run	asynchronously as detached daemon processes; mercurial
       will not	ensure that they exit cleanly.

   mq
       manage a	stack of patches

       This extension lets you work with a stack of  patches  in  a  Mercurial
       repository.  It	manages	two stacks of patches -	all known patches, and
       applied patches (subset of known	patches).

       Known patches are represented as	patch files in the .hg/patches	direc-
       tory. Applied patches are both patch files and changesets.

       Common tasks (use hg help COMMAND for more details):

       create new patch				 qnew
       import existing patch			 qimport

       print patch series			 qseries
       print applied patches			 qapplied

       add known patch to applied stack		 qpush
       remove patch from applied stack		 qpop
       refresh contents	of top applied patch	 qrefresh

       By  default,  mq	 will  automatically  use git patches when required to
       avoid losing file mode changes, copy records,  binary  files  or	 empty
       files creations or deletions. This behavior can be configured with:

       [mq]
       git = auto/keep/yes/no

       If  set	to 'keep', mq will obey	the [diff] section configuration while
       preserving existing git patches upon qrefresh. If set to	'yes' or 'no',
       mq  will	override the [diff] section and	always generate	git or regular
       patches,	possibly losing	data in	the second case.

       It may be desirable for mq changesets to	be kept	in  the	 secret	 phase
       (see hg help phases), which can be enabled with the following setting:

       [mq]
       secret =	True

       You  will by default be managing	a patch	queue named "patches". You can
       create other, independent patch queues with the hg qqueue command.

       If the working directory	contains uncommitted files,  qpush,  qpop  and
       qgoto  abort  immediately.  If -f/--force is used, the changes are dis-
       carded. Setting:

       [mq]
       keepchanges = True

       make them behave	as if --keep-changes were passed, and  non-conflicting
       local  changes will be tolerated	and preserved. If incompatible options
       such as -f/--force or --exact are passed, this setting is ignored.

       This extension used to provide a	strip command. This command now	 lives
       in the strip extension.

   Commands
   Repository creation
   qclone
       clone main and patch repository at same time:

       hg qclone [OPTION]... SOURCE [DEST]

       If source is local, destination will have no patches applied. If	source
       is remote, this command can not check if	patches	are applied in source,
       so cannot guarantee that	patches	are not	applied	in destination.	If you
       clone remote repository,	be sure	before that it has no patches applied.

       Source patch repository is looked for in	<src>/.hg/patches by  default.
       Use -p <url> to change.

       The  patch directory must be a nested Mercurial repository, as would be
       created by hg init --mq.

       Return 0	on success.

       Options:

       --pull use pull protocol	to copy	metadata

       -U, --noupdate
	      do not update the	new working directories

       --uncompressed
	      use uncompressed transfer	(fast over LAN)

       -p,--patches <REPO>
	      location of source patch repository

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

   qinit
       init a new queue	repository (DEPRECATED):

       hg qinit	[-c]

       The queue repository is unversioned by default. If -c/--create-repo  is
       specified,  qinit  will create a	separate nested	repository for patches
       (qinit -c may also be run later to convert an unversioned patch reposi-
       tory  into  a  versioned	one). You can use qcommit to commit changes to
       this queue repository.

       This command is deprecated. Without -c, it's implied by other  relevant
       commands. With -c, use hg init --mq instead.

       Options:

       -c, --create-repo
	      create queue repository

   Change creation
   qcommit
       commit changes in the queue repository (DEPRECATED):

       hg qcommit [OPTION]... [FILE]...

       This command is deprecated; use hg commit --mq instead.

       Options:

       -A, --addremove
	      mark new/missing files as	added/removed before committing

       --close-branch
	      mark a branch head as closed

       --amend
	      amend the	parent of the working directory

       -s, --secret
	      use the secret phase for committing

       -e, --edit
	      invoke editor on commit messages

       --force-close-branch
	      forcibly close branch from a non-head changeset (ADVANCED)

       -i, --interactive
	      use interactive mode

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -S, --subrepos
	      recurse into subrepositories

       [+] marked option can be	specified multiple times

	  aliases: qci

   qnew
       create a	new patch:

       hg qnew [-e] [-m	TEXT] [-l FILE]	PATCH [FILE]...

       qnew  creates  a	 new  patch  on	top of the currently-applied patch (if
       any). The patch will be initialized with	any outstanding	changes	in the
       working	directory. You may also	use -I/--include, -X/--exclude,	and/or
       a list of files after the patch name to add only	 changes  to  matching
       files to	the new	patch, leaving the rest	as uncommitted modifications.

       -u/--user  and  -d/--date can be	used to	set the	(given)	user and date,
       respectively. -U/--currentuser and -D/--currentdate set user to current
       user and	date to	current	date.

       -e/--edit, -m/--message or -l/--logfile set the patch header as well as
       the commit message. If none is specified, the header is empty  and  the
       commit message is '[mq]:	PATCH'.

       Use the -g/--git	option to keep the patch in the	git extended diff for-
       mat. Read the diffs help	topic for more information on why this is  im-
       portant for preserving permission changes and copy/rename information.

       Returns 0 on successful creation	of a new patch.

       Options:

       -e, --edit
	      invoke editor on commit messages

       -f, --force
	      import uncommitted changes (DEPRECATED)

       -g, --git
	      use git extended diff format

       -U, --currentuser
	      add "From: <current user>" to patch

       -u,--user <USER>
	      add "From: <USER>" to patch

       -D, --currentdate
	      add "Date: <current date>" to patch

       -d,--date <DATE>
	      add "Date: <DATE>" to patch

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       [+] marked option can be	specified multiple times

   qrefresh
       update the current patch:

       hg qrefresh [-I]	[-X] [-e] [-m TEXT] [-l	FILE] [-s] [FILE]...

       If  any	file  patterns	are provided, the refreshed patch will contain
       only the	modifications that match those patterns; the remaining modifi-
       cations will remain in the working directory.

       If  -s/--short is specified, files currently included in	the patch will
       be refreshed just like matched files and	remain in the patch.

       If -e/--edit is specified, Mercurial will start your configured	editor
       for  you	 to  enter  a message. In case qrefresh	fails, you will	find a
       backup of your message in .hg/last-message.txt.

       hg add/remove/copy/rename work as usual,	though you might want  to  use
       git-style  patches  (-g/--git  or [diff]	git=1) to track	copies and re-
       names. See the diffs help topic for more	information on	the  git  diff
       format.

       Returns 0 on success.

       Options:

       -e, --edit
	      invoke editor on commit messages

       -g, --git
	      use git extended diff format

       -s, --short
	      refresh only files already in the	patch and specified files

       -U, --currentuser
	      add/update author	field in patch with current user

       -u,--user <USER>
	      add/update author	field in patch with given user

       -D, --currentdate
	      add/update date field in patch with current date

       -d,--date <DATE>
	      add/update date field in patch with given	date

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       [+] marked option can be	specified multiple times

   Change manipulation
   qfold
       fold the	named patches into the current patch:

       hg qfold	[-e] [-k] [-m TEXT] [-l	FILE] PATCH...

       Patches	must  not  yet be applied. Each	patch will be successively ap-
       plied to	the current patch in the order given. If all the patches apply
       successfully,  the current patch	will be	refreshed with the new cumula-
       tive patch, and the folded patches will be deleted. With	-k/--keep, the
       folded patch files will not be removed afterwards.

       The  header for each folded patch will be concatenated with the current
       patch header, separated by a line of * *	*.

       Returns 0 on success.

       Options:

       -e, --edit
	      invoke editor on commit messages

       -k, --keep
	      keep folded patch	files

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

   Change organization
   qapplied
       print the patches already applied:

       hg qapplied [-1]	[-s] [PATCH]

       Returns 0 on success.

       Options:

       -1, --last
	      show only	the preceding applied patch

       -s, --summary
	      print first line of patch	header

   qdelete
       remove patches from queue:

       hg qdelete [-k] [PATCH]...

       The patches must	not be applied,	and at least one  patch	 is  required.
       Exact  patch identifiers	must be	given. With -k/--keep, the patch files
       are preserved in	the patch directory.

       To stop managing	a patch	and move it into permanent history, use	the hg
       qfinish command.

       Options:

       -k, --keep
	      keep patch file

       -r,--rev	<REV[+]>
	      stop managing a revision (DEPRECATED)

       [+] marked option can be	specified multiple times

	  aliases: qremove qrm

   qfinish
       move applied patches into repository history:

       hg qfinish [-a] [REV]...

       Finishes	 the specified revisions (corresponding	to applied patches) by
       moving them out of mq control into regular repository history.

       Accepts a revision range	or the -a/--applied option.  If	 --applied  is
       specified, all applied mq revisions are removed from mq control.	Other-
       wise, the given revisions must be at the	base of	the stack  of  applied
       patches.

       This  can  be especially	useful if your changes have been applied to an
       upstream	repository, or if you are about	to push	your  changes  to  up-
       stream.

       Returns 0 on success.

       Options:

       -a, --applied
	      finish all applied changesets

   qgoto
       push or pop patches until named patch is	at top of stack:

       hg qgoto	[OPTION]... PATCH

       Returns 0 on success.

       Options:

       --keep-changes
	      tolerate non-conflicting local changes

       -f, --force
	      overwrite	any local changes

       --no-backup
	      do not save backup copies	of files

   qguard
       set or print guards for a patch:

       hg qguard [-l] [-n] [PATCH] [-- [+GUARD]... [-GUARD]...]

       Guards control whether a	patch can be pushed. A patch with no guards is
       always pushed. A	patch with a positive guard ("+foo") is	pushed only if
       the  hg qselect command has activated it. A patch with a	negative guard
       ("-foo")	is never pushed	if the hg qselect command has activated	it.

       With no arguments, print	the currently active guards.  With  arguments,
       set guards for the named	patch.

       Note   Specifying negative guards now requires '--'.

       To set guards on	another	patch:

       hg qguard other.patch --	+2.6.17	-stable

       Returns 0 on success.

       Options:

       -l, --list
	      list all patches and guards

       -n, --none
	      drop all guards

   qheader
       print the header	of the topmost or specified patch:

       hg qheader [PATCH]

       Returns 0 on success.

   qnext
       print the name of the next pushable patch:

       hg qnext	[-s]

       Returns 0 on success.

       Options:

       -s, --summary
	      print first line of patch	header

   qpop
       pop the current patch off the stack:

       hg qpop [-a] [-f] [PATCH	| INDEX]

       Without argument, pops off the top of the patch stack. If given a patch
       name, keeps popping off patches until the named patch is	at the top  of
       the stack.

       By  default,  abort  if	the  working  directory	 contains  uncommitted
       changes.	With --keep-changes, abort only	if the uncommitted files over-
       lap  with  patched  files.  With	-f/--force, backup and discard changes
       made to such files.

       Return 0	on success.

       Options:

       -a, --all
	      pop all patches

       -n,--name <NAME>
	      queue name to pop	(DEPRECATED)

       --keep-changes
	      tolerate non-conflicting local changes

       -f, --force
	      forget any local changes to patched files

       --no-backup
	      do not save backup copies	of files

   qprev
       print the name of the preceding applied patch:

       hg qprev	[-s]

       Returns 0 on success.

       Options:

       -s, --summary
	      print first line of patch	header

   qpush
       push the	next patch onto	the stack:

       hg qpush	[-f] [-l] [-a] [--move]	[PATCH | INDEX]

       By  default,  abort  if	the  working  directory	 contains  uncommitted
       changes.	With --keep-changes, abort only	if the uncommitted files over-
       lap with	patched	files. With -f/--force,	backup and patch  over	uncom-
       mitted changes.

       Return 0	on success.

       Options:

       --keep-changes
	      tolerate non-conflicting local changes

       -f, --force
	      apply on top of local changes

       -e, --exact
	      apply the	target patch to	its recorded parent

       -l, --list
	      list patch name in commit	text

       -a, --all
	      apply all	patches

       -m, --merge
	      merge from another queue (DEPRECATED)

       -n,--name <NAME>
	      merge queue name (DEPRECATED)

       --move reorder patch series and apply only the patch

       --no-backup
	      do not save backup copies	of files

   qqueue
       manage multiple patch queues:

       hg qqueue [OPTION] [QUEUE]

       Supports	 switching between different patch queues, as well as creating
       new patch queues	and deleting existing ones.

       Omitting	a queue	name or	specifying -l/--list will show you the	regis-
       tered queues - by default the "normal" patches queue is registered. The
       currently active	queue will be marked with "(active)". Specifying --ac-
       tive will print only the	name of	the active queue.

       To create a new queue, use -c/--create. The queue is automatically made
       active, except in the case where	there are  applied  patches  from  the
       currently  active  queue	in the repository. Then	the queue will only be
       created and switching will fail.

       To delete an existing queue, use	--delete. You cannot delete  the  cur-
       rently active queue.

       Returns 0 on success.

       Options:

       -l, --list
	      list all available queues

       --active
	      print name of active queue

       -c, --create
	      create new queue

       --rename
	      rename active queue

       --delete
	      delete reference to queue

       --purge
	      delete queue, and	remove patch dir

   qrename
       rename a	patch:

       hg qrename PATCH1 [PATCH2]

       With one	argument, renames the current patch to PATCH1.	With two argu-
       ments, renames PATCH1 to	PATCH2.

       Returns 0 on success.

	  aliases: qmv

   qrestore
       restore the queue state saved by	a revision (DEPRECATED):

       hg qrestore [-d]	[-u] REV

       This command is deprecated, use hg rebase instead.

       Options:

       -d, --delete
	      delete save entry

       -u, --update
	      update queue working directory

   qsave
       save current queue state	(DEPRECATED):

       hg qsave	[-m TEXT] [-l FILE] [-c] [-n NAME] [-e]	[-f]

       This command is deprecated, use hg rebase instead.

       Options:

       -c, --copy
	      copy patch directory

       -n,--name <NAME>
	      copy directory name

       -e, --empty
	      clear queue status file

       -f, --force
	      force copy

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

   qselect
       set or print guarded patches to push:

       hg qselect [OPTION]... [GUARD]...

       Use the hg qguard command to set	or print guards	on patch, then use qs-
       elect  to tell mq which guards to use. A	patch will be pushed if	it has
       no guards or any	positive guards	match the  currently  selected	guard,
       but  will not be	pushed if any negative guards match the	current	guard.
       For example:

       qguard foo.patch	-- -stable    (negative	guard)
       qguard bar.patch	   +stable    (positive	guard)
       qselect stable

       This activates the "stable" guard. mq will skip foo.patch  (because  it
       has  a  negative	 match)	 but push bar.patch (because it	has a positive
       match).

       With no arguments, prints the currently active guards.  With one	 argu-
       ment, sets the active guard.

       Use  -n/--none  to deactivate guards (no	other arguments	needed).  When
       no guards are active, patches with  positive  guards  are  skipped  and
       patches with negative guards are	pushed.

       qselect	can  change  the  guards  on  applied patches. It does not pop
       guarded patches by default. Use --pop to	pop back to the	 last  applied
       patch  that is not guarded. Use --reapply (which	implies	--pop) to push
       back to the current patch afterwards, but skip guarded patches.

       Use -s/--series to print	a list of all guards in	the  series  file  (no
       other arguments needed).	Use -v for more	information.

       Returns 0 on success.

       Options:

       -n, --none
	      disable all guards

       -s, --series
	      list all guards in series	file

       --pop  pop to before first guarded applied patch

       --reapply
	      pop, then	reapply	patches

   qseries
       print the entire	series file:

       hg qseries [-ms]

       Returns 0 on success.

       Options:

       -m, --missing
	      print patches not	in series

       -s, --summary
	      print first line of patch	header

   qtop
       print the name of the current patch:

       hg qtop [-s]

       Returns 0 on success.

       Options:

       -s, --summary
	      print first line of patch	header

   qunapplied
       print the patches not yet applied:

       hg qunapplied [-1] [-s] [PATCH]

       Returns 0 on success.

       Options:

       -1, --first
	      show only	the first patch

       -s, --summary
	      print first line of patch	header

   File	content	management
   qdiff
       diff of the current patch and subsequent	modifications:

       hg qdiff	[OPTION]... [FILE]...

       Shows  a	 diff  which includes the current patch	as well	as any changes
       which have been made in the working directory since  the	 last  refresh
       (thus showing what the current patch would become after a qrefresh).

       Use  hg	diff if	 you  only want	to see the changes made	since the last
       qrefresh, or hg export qtip if you want to see changes made by the cur-
       rent patch without including changes made since the qrefresh.

       Returns 0 on success.

       Options:

       -a, --text
	      treat all	files as text

       -g, --git
	      use git extended diff format

       --binary
	      generate binary diffs in git mode	(default)

       --nodates
	      omit dates from diff headers

       --noprefix
	      omit a/ and b/ prefixes from filenames

       -p, --show-function
	      show which function each change is in

       --reverse
	      produce a	diff that undoes the changes

       -w, --ignore-all-space
	      ignore white space when comparing	lines

       -b, --ignore-space-change
	      ignore changes in	the amount of white space

       -B, --ignore-blank-lines
	      ignore changes whose lines are all blank

       -Z, --ignore-space-at-eol
	      ignore changes in	whitespace at EOL

       -U,--unified <NUM>
	      number of	lines of context to show

       --stat output diffstat-style summary of changes

       --root _DIR_
	      produce diffs relative to	subdirectory

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   Change import/export
   qimport
       import a	patch or existing changeset:

       hg qimport [-e] [-n NAME] [-f] [-g] [-P]	[-r REV]... [FILE]...

       The  patch is inserted into the series after the	last applied patch. If
       no patches have been applied, qimport prepends the patch	to the series.

       The patch will have the same name as its	source file unless you give it
       a new one with -n/--name.

       You  can	register an existing patch inside the patch directory with the
       -e/--existing flag.

       With -f/--force,	an existing patch of the same name will	 be  overwrit-
       ten.

       An  existing  changeset	may  be	 placed	under mq control with -r/--rev
       (e.g. qimport --rev . -n	patch will place the current revision under mq
       control).  With	-g/--git, patches imported with	--rev will use the git
       diff format. See	the diffs help topic for information on	 why  this  is
       important   for	 preserving  rename/copy  information  and  permission
       changes.	Use hg qfinish to remove changesets from mq control.

       To import a patch from standard input, pass - as	the patch file.	  When
       importing from standard input, a	patch name must	be specified using the
       --name flag.

       To import an existing patch while renaming it:

       hg qimport -e existing-patch -n new-name

       Returns 0 if import succeeded.

       Options:

       -e, --existing
	      import file in patch directory

       -n,--name <NAME>
	      name of patch file

       -f, --force
	      overwrite	existing files

       -r,--rev	<REV[+]>
	      place existing revisions under mq	control

       -g, --git
	      use git extended diff format

       -P, --push
	      qpush after importing

       [+] marked option can be	specified multiple times

   narrow
       create clones which fetch history data for subset of files  (EXPERIMEN-
       TAL)

   Commands
   Uncategorized commands
   tracked
       show or change the current narrowspec:

       hg tracked [OPTIONS]... [REMOTE]

       With  no	 argument, shows the current narrowspec	entries, one per line.
       Each line will be prefixed with 'I' or 'X'  for	included  or  excluded
       patterns, respectively.

       The narrowspec is comprised of expressions to match remote files	and/or
       directories that	should be pulled into your client.  The	narrowspec has
       include	and  exclude  expressions,  with  excludes always trumping in-
       cludes: that is,	if a file matches an exclude expression,  it  will  be
       excluded	 even  if  it  also  matches an	include	expression.  Excluding
       files that were never included has no effect.

       Each included or	excluded entry is in the format	described by 'hg  help
       patterns'.

       The  options  allow  you	to add or remove included and excluded expres-
       sions.

       If --clear is specified,	then all previous includes  and	 excludes  are
       DROPPED	and  replaced  by  the	new ones specified to --addinclude and
       --addexclude.  If --clear is specified without any further options, the
       narrowspec will be empty	and will not match any files.

       --import-rules  accepts a path to a file	containing rules, allowing you
       to add --addinclude, --addexclude rules in bulk.	Like the other include
       and exclude switches, the changes are applied immediately.

       Options:

       --addinclude _VALUE[+]_
	      new paths	to include

       --removeinclude _VALUE[+]_
	      old paths	to no longer include

       --addexclude _VALUE[+]_
	      new paths	to exclude

       --import-rules _VALUE_
	      import narrowspecs from a	file

       --removeexclude _VALUE[+]_
	      old paths	to no longer exclude

       --clear
	      whether to replace the existing narrowspec

       --force-delete-local-changes
	      forces deletion of local changes when narrowing

       --update-working-copy
	      update working copy when the store has changed

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   notify
       hooks for sending email push notifications

       This  extension	implements  hooks  to  send  email  notifications when
       changesets are sent from	or received by the local repository.

       First, enable the extension as explained	in  hg	help  extensions,  and
       register	 the  hook you want to run. incoming and changegroup hooks are
       run when	changesets are received, while outgoing	hooks are for  change-
       sets sent to another repository:

       [hooks]
       # one email for each incoming changeset
       incoming.notify = python:hgext.notify.hook
       # one email for all incoming changesets
       changegroup.notify = python:hgext.notify.hook

       # one email for all outgoing changesets
       outgoing.notify = python:hgext.notify.hook

       This  registers	the hooks. To enable notification, subscribers must be
       assigned	to repositories. The [usersubs]	section	maps multiple  reposi-
       tories  to  a given recipient. The [reposubs] section maps multiple re-
       cipients	to a single repository:

       [usersubs]
       # key is	subscriber email, value	is a comma-separated list of repo patterns
       user@host = pattern

       [reposubs]
       # key is	repo pattern, value is a comma-separated list of subscriber emails
       pattern = user@host

       A pattern is a glob matching the	absolute path to a repository, option-
       ally  combined  with  a	revset	expression.  A	revset	expression, if
       present,	is separated from the glob by a	hash. Example:

       [reposubs]
       */widgets#branch(release) = qa-team@example.com

       This sends to qa-team@example.com whenever a changeset on  the  release
       branch triggers a notification in any repository	ending in widgets.

       In  order  to  place  them under	direct user management,	[usersubs] and
       [reposubs] sections may be placed in a separate hgrc file and  incorpo-
       rated by	reference:

       [notify]
       config =	/path/to/subscriptionsfile

       Notifications  will  not	 be sent until the notify.test value is	set to
       False; see below.

       Notifications content can be tweaked with the  following	 configuration
       entries:

       notify.test
	      If  True,	 print messages	to stdout instead of sending them. De-
	      fault: True.

       notify.sources
	      Space-separated list of change sources. Notifications are	 acti-
	      vated  only  when	 a changeset's source is in this list. Sources
	      may be:

	      serve

		     changesets	received via http or ssh

	      pull

		     changesets	received via hg	pull

	      unbundle

		     changesets	received via hg	unbundle

	      push

		     changesets	sent or	received via hg	push

	      bundle

		     changesets	sent via hg unbundle

	      Default: serve.

       notify.strip
	      Number of	leading	slashes	to strip from url paths.  By  default,
	      notifications  reference	repositories with their	absolute path.
	      notify.strip lets	you turn them into relative paths.  For	 exam-
	      ple,   notify.strip=3  will  change  /long/path/repository  into
	      repository. Default: 0.

       notify.domain
	      Default email domain for sender or recipients with  no  explicit
	      domain.

       notify.style
	      Style file to use	when formatting	emails.

       notify.template
	      Template to use when formatting emails.

       notify.incoming
	      Template	to  use	 when  run as an incoming hook,	overriding no-
	      tify.template.

       notify.outgoing
	      Template to use when run as an  outgoing	hook,  overriding  no-
	      tify.template.

       notify.changegroup
	      Template	to  use	when running as	a changegroup hook, overriding
	      notify.template.

       notify.maxdiff
	      Maximum number of	diff lines to include in  notification	email.
	      Set  to  0  to disable the diff, or -1 to	include	all of it. De-
	      fault: 300.

       notify.maxdiffstat
	      Maximum number of	diffstat  lines	 to  include  in  notification
	      email. Set to -1 to include all of it. Default: -1.

       notify.maxsubject
	      Maximum  number  of characters in	email's	subject	line. Default:
	      67.

       notify.diffstat
	      Set to True to include a diffstat	before diff content.  Default:
	      True.

       notify.showfunc
	      If  set,	override  diff.showfunc	for the	diff content. Default:
	      None.

       notify.merge
	      If True, send notifications for merge changesets.	Default: True.

       notify.mbox
	      If set, append mails to this mbox	file instead of	 sending.  De-
	      fault: None.

       notify.fromauthor
	      If  set,	use  the committer of the first	changeset in a change-
	      group for	the "From" field of the	notification mail. If not set,
	      take the user from the pushing repo.  Default: False.

       If  set,	the following entries will also	be used	to customize the noti-
       fications:

       email.from
	      Email From address to use	if none	can be found in	the  generated
	      email content.

       web.baseurl
	      Root repository URL to combine with repository paths when	making
	      references. See also notify.strip.

   pager
       browse command output with an external pager (DEPRECATED)

       Forcibly	enable paging for individual commands that don't typically re-
       quest  pagination  with the attend-<command> option. This setting takes
       precedence over ignore options and defaults:

       [pager]
       attend-cat = false

   patchbomb
       command to send changesets as (a	series of) patch emails

       The series is started off with a	"[PATCH	0 of N]"  introduction,	 which
       describes the series as a whole.

       Each  patch email has a Subject line of "[PATCH M of N] ...", using the
       first line of the changeset description as the subject text.  The  mes-
       sage contains two or three body parts:

       o The changeset description.

       o [Optional] The	result of running diffstat on the patch.

       o The patch itself, as generated	by hg export.

       Each  message  refers  to the first in the series using the In-Reply-To
       and References headers, so they will show up as a sequence in  threaded
       mail and	news readers, and in mail archives.

       To configure other defaults, add	a section like this to your configura-
       tion file:

       [email]
       from = My Name <my@email>
       to = recipient1,	recipient2, ...
       cc = cc1, cc2, ...
       bcc = bcc1, bcc2, ...
       reply-to	= address1, address2, ...

       Use [patchbomb] as configuration	section	name if	you need  to  override
       global [email] address settings.

       Then you	can use	the hg email command to	mail a series of changesets as
       a patchbomb.

       You can also either configure the method	option in the email section to
       be  a sendmail compatible mailer	or fill	out the	[smtp] section so that
       the patchbomb extension can automatically send patchbombs directly from
       the commandline.	See the	[email]	and [smtp] sections in hgrc(5) for de-
       tails.

       By default, hg email will prompt	for a To or CC header if  you  do  not
       supply  one  via	 configuration	or the command line.  You can override
       this to never prompt by configuring an empty value:

       [email]
       cc =

       You can control the default inclusion of	an introduction	 message  with
       the  patchbomb.intro  configuration option. The configuration is	always
       overwritten by command line flags like --intro and --desc:

       [patchbomb]
       intro=auto   # include introduction message if more than	1 patch	(default)
       intro=never  # never include an introduction message
       intro=always # always include an	introduction message

       You can specify a template for flags to be added	in  subject  prefixes.
       Flags specified by --flag option	are exported as	{flags}	keyword:

       [patchbomb]
       flagtemplate = "{separate(' ',
				 ifeq(branch, 'default', '', branch|upper),
				 flags)}"

       You  can	set patchbomb to always	ask for	confirmation by	setting	patch-
       bomb.confirm to true.

   Commands
   Change import/export
   email
       send changesets by email:

       hg email	[OPTION]... [DEST]...

       By default, diffs are sent in the format	generated by  hg  export,  one
       per  message.  The  series starts with a	"[PATCH	0 of N]" introduction,
       which describes the series as a whole.

       Each patch email	has a Subject line of "[PATCH M	of N] ...", using  the
       first  line of the changeset description	as the subject text.  The mes-
       sage contains two or three parts. First,	the changeset description.

       With the	-d/--diffstat option, if the diffstat  program	is  installed,
       the result of running diffstat on the patch is inserted.

       Finally,	the patch itself, as generated by hg export.

       With the	-d/--diffstat or --confirm options, you	will be	presented with
       a final summary of all messages and asked for confirmation  before  the
       messages	are sent.

       By default the patch is included	as text	in the email body for easy re-
       viewing.	Using the -a/--attach option will instead create an attachment
       for  the	 patch.	With -i/--inline an inline attachment will be created.
       You can include a patch both as text in the email body and as a regular
       or  an  inline  attachment  by combining	the -a/--attach	or -i/--inline
       with the	--body option.

       With -B/--bookmark changesets reachable by the given bookmark  are  se-
       lected.

       With  -o/--outgoing,  emails will be generated for patches not found in
       the destination repository (or only those which are  ancestors  of  the
       specified revisions if any are provided)

       With -b/--bundle, changesets are	selected as for	--outgoing, but	a sin-
       gle email containing a binary Mercurial bundle as an attachment will be
       sent.  Use the patchbomb.bundletype config option to control the	bundle
       type as with hg bundle --type.

       With -m/--mbox, instead of previewing each patchbomb message in a pager
       or  sending  the	 messages directly, it will create a UNIX mailbox file
       with the	patch emails. This mailbox file	can be previewed with any mail
       user agent which	supports UNIX mbox files.

       With  -n/--test,	 all  steps  will run, but mail	will not be sent.  You
       will be prompted	for an email recipient address,	a subject and  an  in-
       troductory message describing the patches of your patchbomb.  Then when
       all is done, patchbomb messages are displayed.

       In case email sending fails, you	will find a backup of your series  in-
       troductory message in .hg/last-email.txt.

       The default behavior of this command can	be customized through configu-
       ration. (See hg help patchbomb for details)

       Examples:

       hg email	-r 3000		 # send	patch 3000 only
       hg email	-r 3000	-r 3001	 # send	patches	3000 and 3001
       hg email	-r 3000:3005	 # send	patches	3000 through 3005
       hg email	3000		 # send	patch 3000 (deprecated)

       hg email	-o		 # send	all patches not	in default
       hg email	-o DEST		 # send	all patches not	in DEST
       hg email	-o -r 3000	 # send	all ancestors of 3000 not in default
       hg email	-o -r 3000 DEST	 # send	all ancestors of 3000 not in DEST

       hg email	-B feature	 # send	all ancestors of feature bookmark

       hg email	-b		 # send	bundle of all patches not in default
       hg email	-b DEST		 # send	bundle of all patches not in DEST
       hg email	-b -r 3000	 # bundle of all ancestors of 3000 not in default
       hg email	-b -r 3000 DEST	 # bundle of all ancestors of 3000 not in DEST

       hg email	-o -m mbox &&	 # generate an mbox file...
	 mutt -R -f mbox	 # ... and view	it with	mutt
       hg email	-o -m mbox &&	 # generate an mbox file ...
	 formail -s sendmail \	 # ... and use formail to send from the	mbox
	   -bm -t < mbox	 # ... using sendmail

       Before using this command, you will need	to enable email	in your	 hgrc.
       See the [email] section in hgrc(5) for details.

       Options:

       -g, --git
	      use git extended diff format

       --plain
	      omit hg patch header

       -o, --outgoing
	      send changes not found in	the target repository

       -b, --bundle
	      send changes not in target as a binary bundle

       -B,--bookmark <BOOKMARK>
	      send changes only	reachable by given bookmark

       --bundlename _NAME_
	      name of the bundle attachment file (default: bundle)

       -r,--rev	<REV[+]>
	      a	revision to send

       --force
	      run even when remote repository is unrelated (with -b/--bundle)

       --base _REV[+]_
	      a	 base  changeset  to  specify  instead	of a destination (with
	      -b/--bundle)

       --intro
	      send an introduction email for a single patch

       --body send patches as inline message text (default)

       -a, --attach
	      send patches as attachments

       -i, --inline
	      send patches as inline attachments

       --bcc _EMAIL[+]_
	      email addresses of blind carbon copy recipients

       -c,--cc <EMAIL[+]>
	      email addresses of copy recipients

       --confirm
	      ask for confirmation before sending

       -d, --diffstat
	      add diffstat output to messages

       --date _DATE_
	      use the given date as the	sending	date

       --desc _FILE_
	      use the given file as the	series description

       -f,--from <EMAIL>
	      email address of sender

       -n, --test
	      print messages that would	be sent

       -m,--mbox <FILE>
	      write messages to	mbox file instead of sending them

       --reply-to _EMAIL[+]_
	      email addresses replies should be	sent to

       -s,--subject <TEXT>
	      subject of first message (intro or single	patch)

       --in-reply-to _MSGID_
	      message identifier to reply to

       --flag _FLAG[+]_
	      flags to add in subject prefixes

       -t,--to <EMAIL[+]>
	      email addresses of recipients

       -e,--ssh	<CMD>
	      specify ssh command to use

       --remotecmd _CMD_
	      specify hg command to run	on the remote side

       --insecure
	      do not verify server certificate (ignoring web.cacerts config)

       [+] marked option can be	specified multiple times

   phabricator
       simple Phabricator integration (EXPERIMENTAL)

       This extension provides a phabsend  command  which  sends  a  stack  of
       changesets  to Phabricator, and a phabread command which	prints a stack
       of revisions in a format	suitable for hg	import,	and a phabupdate  com-
       mand to update statuses in batch.

       By  default,  Phabricator  requires  Test Plan which might prevent some
       changeset from being sent. The requirement could	be disabled by	chang-
       ing differential.require-test-plan-field	config server side.

       Config:

       [phabricator]
       # Phabricator URL
       url = https://phab.example.com/

       # Repo callsign.	If a repo has a	URL https://$HOST/diffusion/FOO, then its
       # callsign is "FOO".
       callsign	= FOO

       # curl command to use. If not set (default), use	builtin	HTTP library to
       # communicate. If set, use the specified	curl command. This could be useful
       # if you	need to	specify	advanced options that is not easily supported by
       # the internal library.
       curlcmd = curl --connect-timeout	2 --retry 3 --silent

       [auth]
       example.schemes = https
       example.prefix =	phab.example.com

       # API token. Get	it from	https://$HOST/conduit/login/
       example.phabtoken = cli-xxxxxxxxxxxxxxxxxxxxxxxxxxxx

   Commands
   Change import/export
   phabread
       print patches from Phabricator suitable for importing:

       hg phabread DREVSPEC [OPTIONS]

       DREVSPEC	 could be a Differential Revision identity, like D123, or just
       the number 123. It could	also have common operators like	+, -, &, (,  )
       for complex queries. Prefix : could be used to select a stack.

       abandoned,  accepted,  closed, needsreview, needsrevision could be used
       to filter patches by status. For	performance reason, they  only	repre-
       sent a subset of	non-status selections and cannot be used alone.

       For example, :D6+8-(2+D4) selects a stack up to D6, plus	D8 and exclude
       D2 and D4. :D9 &	needsreview selects  "Needs  Review"  revisions	 in  a
       stack up	to D9.

       If  --stack  is	given,	follow	dependencies  information and read all
       patches.	 It is equivalent to the : operator.

       Options:

       --stack
	      read dependencies

       --test-vcr _VALUE_
	      Path to a	vcr file. If nonexistent, will record a	new vcr	 tran-
	      script,  otherwise  will mock all	http requests using the	speci-
	      fied vcr file. (ADVANCED)

   phabsend
       upload changesets to Phabricator:

       hg phabsend REV [OPTIONS]

       If there	are multiple revisions specified, they will be send as a stack
       with  a	linear	dependencies relationship using	the order specified by
       the revset.

       For the first time uploading changesets,	local tags will	be created  to
       maintain	the association. After the first time, phabsend	will check ob-
       sstore and tags information so it can figure out	whether	to  update  an
       existing	Differential Revision, or create a new one.

       If --amend is set, update commit	messages so they have the Differential
       Revision	URL, remove related tags. This is  similar  to	what  arcanist
       will  do,  and is more desired in author-push workflows.	Otherwise, use
       local tags to record the	Differential Revision association.

       The --confirm option lets you confirm changesets	before	sending	 them.
       You  can	 also  add following to	your configuration file	to make	it de-
       fault behaviour:

       [phabsend]
       confirm = true

       phabsend	will check  obsstore  and  the	above  association  to	decide
       whether	to  update  an existing	Differential Revision, or create a new
       one.

       Options:

       -r,--rev	<REV[+]>
	      revisions	to send

       --amend
	      update commit messages (default: True)

       --reviewer _VALUE[+]_
	      specify reviewers

       --blocker _VALUE[+]_
	      specify blocking reviewers

       -m,--comment <VALUE>
	      add a comment to Revisions with new/updated Diffs

       --confirm
	      ask for confirmation before sending

       --test-vcr _VALUE_
	      Path to a	vcr file. If nonexistent, will record a	new vcr	 tran-
	      script,  otherwise  will mock all	http requests using the	speci-
	      fied vcr file. (ADVANCED)

       [+] marked option can be	specified multiple times

   phabupdate
       update Differential Revision in batch:

       hg phabupdate DREVSPEC [OPTIONS]

       DREVSPEC	selects	revisions. See hg help phabread	for its	usage.

       Options:

       --accept
	      accept revisions

       --reject
	      reject revisions

       --abandon
	      abandon revisions

       --reclaim
	      reclaim revisions

       -m,--comment <VALUE>
	      comment on the last revision

       --test-vcr _VALUE_
	      Path to a	vcr file. If nonexistent, will record a	new vcr	 tran-
	      script,  otherwise  will mock all	http requests using the	speci-
	      fied vcr file. (ADVANCED)

   Uncategorized commands
   purge
       command to delete untracked files from the working directory

   Commands
   Repository maintenance
   purge
       removes files not tracked by Mercurial:

       hg purge	[OPTION]... [DIR]...

       Delete files not	known to Mercurial. This is useful to test  local  and
       uncommitted changes in an otherwise-clean source	tree.

       This means that purge will delete the following by default:

       o Unknown files:	files marked with "?" by hg status

       o Empty	directories: in	fact Mercurial ignores directories unless they
	 contain files under source control management

       But it will leave untouched:

       o Modified and unmodified tracked files

       o Ignored files (unless --all is	specified)

       o New files added to the	repository (with hg add)

       The --files and --dirs options can be used to direct  purge  to	delete
       only files, only	directories, or	both. If neither option	is given, both
       will be deleted.

       If directories are given	on the command line, only files	in  these  di-
       rectories are considered.

       Be  careful with	purge, as you could irreversibly delete	some files you
       forgot to add to	the repository.	If you only want to print the list  of
       files that this program would delete, use the --print option.

       Options:

       -a, --abort-on-err
	      abort if an error	occurs

       --all  purge ignored files too

       --dirs purge empty directories

       --files
	      purge files

       -p, --print
	      print filenames instead of deleting them

       -0, --print0
	      end filenames with NUL, for use with xargs (implies -p/--print)

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

	  aliases: clean

   rebase
       command to move sets of revisions to a different	ancestor

       This  extension	lets  you  rebase  changesets in an existing Mercurial
       repository.

       For more	information: https://mercurial-scm.org/wiki/RebaseExtension

   Commands
   Change manipulation
   rebase
       move changeset (and descendants)	to a different branch:

       hg rebase [-s REV | -b REV] [-d REV] [OPTION]

       Rebase uses repeated merging to graft changesets	from one part of  his-
       tory  (the  source)  onto another (the destination). This can be	useful
       for linearizing local changes relative to a master development tree.

       Published commits cannot	be rebased (see	hg help	phases).  To copy com-
       mits, see hg help graft.

       If  you	don't specify a	destination changeset (-d/--dest), rebase will
       use the same logic as hg	merge to pick a	destination.  if  the  current
       branch  contains	 exactly one other head, the other head	is merged with
       by default.  Otherwise, an explicit revision with which to  merge  with
       must  be	provided.  (destination	changeset is not modified by rebasing,
       but new changesets are added as its descendants.)

       Here are	the ways to select changesets:

	  1. Explicitly	select them using --rev.

	  2. Use --source to select a root changeset and include  all  of  its
	     descendants.

	  3. Use  --base to select a changeset;	rebase will find ancestors and
	     their descendants which are not also ancestors  of	 the  destina-
	     tion.

	  4. If	 you  do not specify any of --rev, --source, or	--base,	rebase
	     will use --base . as above.

       If --source or --rev is used, special names SRC and ALLSRC can be  used
       in --dest. Destination would be calculated per source revision with SRC
       substituted by that single source revision and  ALLSRC  substituted  by
       all source revisions.

       Rebase will destroy original changesets unless you use --keep.  It will
       also move your bookmarks	(even if you do).

       Some changesets may be dropped if they do not contribute	changes	 (e.g.
       merges from the destination branch).

       Unlike  merge, rebase will do nothing if	you are	at the branch tip of a
       named branch with two heads. You	will need to explicitly	specify	source
       and/or destination.

       If you need to use a tool to automate merge/conflict decisions, you can
       specify one with	--tool,	see hg help merge-tools.   As  a  caveat:  the
       tool  will  not be used to mediate when a file was deleted, there is no
       hook presently available	for this.

       If a rebase is interrupted to manually resolve a	conflict,  it  can  be
       continued  with --continue/-c, aborted with --abort/-a, or stopped with
       --stop.

       Examples:

       o move "local changes" (current commit back to branching	point) to  the
	 current branch	tip after a pull:

	 hg rebase

       o move a	single changeset to the	stable branch:

	 hg rebase -r 5f493448 -d stable

       o splice	a commit and all its descendants onto another part of history:

	 hg rebase --source c0c3 --dest	4cf9

       o rebase	 everything  on	a branch marked	by a bookmark onto the default
	 branch:

	 hg rebase --base myfeature --dest default

       o collapse a sequence of	changes	into a single commit:

	 hg rebase --collapse -r 1520:1525 -d .

       o move a	named branch while preserving its name:

	 hg rebase -r "branch(featureX)" -d 1.3	--keepbranches

       o stabilize orphaned changesets so history looks	linear:

	 hg rebase -r 'orphan()-obsolete()' -d 'first(max((successors(max(roots(ALLSRC)	& ::SRC)^)-obsolete())::) + max(::((roots(ALLSRC) & ::SRC)^)-obsolete()))'

       Configuration Options:

       You can make rebase require a destination if you	set the	following con-
       fig option:

       [commands]
       rebase.requiredest = True

       By  default,  rebase  will close	the transaction	after each commit. For
       performance purposes, you can configure rebase to use a single transac-
       tion  across the	entire rebase. WARNING:	This setting introduces	a sig-
       nificant	risk of	losing the work	you've done in a rebase	if the	rebase
       aborts unexpectedly:

       [rebase]
       singletransaction = True

       By default, rebase writes to the	working	copy, but you can configure it
       to run in-memory	for better performance.	When the rebase	is not	moving
       the  parent(s)  of  the	working	 copy  (AKA the	"currently checked out
       changesets"), this may also allow it to run even	if the working copy is
       dirty:

       [rebase]
       experimental.inmemory = True

       Return Values:

       Returns	0  on  success,	1 if nothing to	rebase or there	are unresolved
       conflicts.

       Options:

       -s,--source <REV>
	      rebase the specified changeset and descendants

       -b,--base <REV>
	      rebase everything	from branching point of	specified changeset

       -r,--rev	<REV[+]>
	      rebase these revisions

       -d,--dest <REV>
	      rebase onto the specified	changeset

       --collapse
	      collapse the rebased changesets

       -m,--message <TEXT>
	      use text as collapse commit message

       -e, --edit
	      invoke editor on commit messages

       -l,--logfile <FILE>
	      read collapse commit message from	file

       -k, --keep
	      keep original changesets

       --keepbranches
	      keep original branch names

       -D, --detach
	      (DEPRECATED)

       -i, --interactive
	      (DEPRECATED)

       -t,--tool <VALUE>
	      specify merge tool

       --stop stop interrupted rebase

       -c, --continue
	      continue an interrupted rebase

       -a, --abort
	      abort an interrupted rebase

       --auto-orphans _VALUE_
	      automatically rebase orphan revisions in	the  specified	revset
	      (EXPERIMENTAL)

       -n, --dry-run
	      do not perform actions, just print output

       -T,--template <TEMPLATE>
	      display with template

       --confirm
	      ask before applying actions

       [+] marked option can be	specified multiple times

   record
       commands	 to  interactively  select changes for commit/qrefresh (DEPRE-
       CATED)

       The feature provided by this extension has been moved into core	Mercu-
       rial as hg commit --interactive.

   Commands
   Change creation
   qrecord
       interactively record a new patch:

       hg qrecord [OPTION]... PATCH [FILE]...

       See hg help qnew	& hg help record for more information and usage.

   record
       interactively select changes to commit:

       hg record [OPTION]... [FILE]...

       If  a  list of files is omitted,	all changes reported by	hg status will
       be candidates for recording.

       See hg help dates for a list of formats valid for -d/--date.

       If using	the text interface (see	hg help	config), you will be  prompted
       for whether to record changes to	each modified file, and	for files with
       multiple	changes, for each change to use. For each query, the following
       responses are possible:

       y - record this change
       n - skip	this change
       e - edit	this change manually

       s - skip	remaining changes to this file
       f - record remaining changes to this file

       d - done, skip remaining	changes	and files
       a - record all changes to all remaining files
       q - quit, recording no changes

       ? - display help

       This command is not available when committing a merge.

       Options:

       -A, --addremove
	      mark new/missing files as	added/removed before committing

       --close-branch
	      mark a branch head as closed

       --amend
	      amend the	parent of the working directory

       -s, --secret
	      use the secret phase for committing

       -e, --edit
	      invoke editor on commit messages

       --force-close-branch
	      forcibly close branch from a non-head changeset (ADVANCED)

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       -m,--message <TEXT>
	      use text as commit message

       -l,--logfile <FILE>
	      read commit message from file

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

       -S, --subrepos
	      recurse into subrepositories

       -w, --ignore-all-space
	      ignore white space when comparing	lines

       -b, --ignore-space-change
	      ignore changes in	the amount of white space

       -B, --ignore-blank-lines
	      ignore changes whose lines are all blank

       -Z, --ignore-space-at-eol
	      ignore changes in	whitespace at EOL

       [+] marked option can be	specified multiple times

   releasenotes
       generate	release	notes from commit messages (EXPERIMENTAL)

       It  is  common to maintain files	detailing changes in a project between
       releases. Maintaining these files can be	difficult and time  consuming.
       The  hg	releasenotes command  provided	by  this  extension  makes the
       process simpler by automating it.

   Commands
   Change navigation
   releasenotes
       parse release notes from	commit messages	into an	output file:

       hg releasenotes [-r REV]	[-c] FILE

       Given an	output file and	set of revisions, this command will parse com-
       mit messages for	release	notes then add them to the output file.

       Release notes are defined in commit messages as ReStructuredText	direc-
       tives. These have the form:

       .. directive:: title

	  content

       Each directive maps to an output	section	in a generated	release	 notes
       file,  which  itself is ReStructuredText. For example, the .. feature::
       directive would map to a	New Features section.

       Release note directives can  be	either	short-form  or	long-form.  In
       short-  form,  title  is	 omitted and the release note is rendered as a
       bullet list. In long form, a sub-section	with the title title is	 added
       to the section.

       The  FILE  argument  controls the output	file to	write gathered release
       notes to. The format of the file	is:

       Section 1
       =========

       ...

       Section 2
       =========

       ...

       Only sections with defined release notes	are emitted.

       If a section only has short-form	notes, it will consist of bullet list:

       Section
       =======

       * Release note 1
       * Release note 2

       If a section has	long-form notes, sub-sections will be emitted:

       Section
       =======

       Note 1 Title
       ------------

       Description of the first	long-form note.

       Note 2 Title
       ------------

       Description of the second long-form note.

       If the FILE argument points to an existing  file,  that	file  will  be
       parsed  for  release notes having the format that would be generated by
       this command. The notes from the	 processed  commit  messages  will  be
       merged into this	parsed set.

       During release notes merging:

       o Duplicate items are automatically ignored

       o Items	that are different are automatically ignored if	the similarity
	 is greater than a threshold.

       This means that the release notes file  can  be	updated	 independently
       from this command and changes should not	be lost	when running this com-
       mand on that file. A particular use case	for this is to tweak the word-
       ing  of	a  release  note  after	it has been added to the release notes
       file.

       The -c/--check option checks the	commit	message	 for  invalid  admoni-
       tions.

       The  -l/--list option, presents the user	with a list of existing	avail-
       able admonitions	along with their title.	This also includes the	custom
       admonitions (if any).

       Options:

       -r,--rev	<REV>
	      revisions	to process for release notes

       -c, --check
	      checks for validity of admonitions (if any)

       -l, --list
	      list the available admonitions with their	title

   Uncategorized commands
   relink
       recreates hardlinks between repository clones

   Commands
   Repository maintenance
   relink
       recreate	hardlinks between two repositories:

       hg relink [ORIGIN]

       When  repositories  are	cloned	locally,  their	 data  files  will  be
       hardlinked so that they only use	the space of a single repository.

       Unfortunately, subsequent  pulls	 into  either  repository  will	 break
       hardlinks  for  any  files  touched by the new changesets, even if both
       repositories end	up pulling the same changes.

       Similarly, passing --rev	to "hg clone" will fail	to use any  hardlinks,
       falling back to a complete copy of the source repository.

       This  command lets you recreate those hardlinks and reclaim that	wasted
       space.

       This repository will be relinked	to share space with ORIGIN, which must
       be on the same local disk. If ORIGIN is omitted,	looks for "default-re-
       link", then "default", in [paths].

       Do not attempt any read operations on this repository while the command
       is running. (Both repositories will be locked against writes.)

   remotefilelog
       remotefilelog  causes Mercurial to lazilly fetch	file contents (EXPERI-
       MENTAL)

       This extension is HIGHLY	EXPERIMENTAL. There are	NO BACKWARDS  COMPATI-
       BILITY  GUARANTEES.  This means that repositories created with this ex-
       tension may only	be usable  with	 the  exact  version  of  this	exten-
       sion/Mercurial that was used. The extension attempts to enforce this in
       order to	prevent	repository corruption.

       remotefilelog works by fetching file contents lazily and	 storing  them
       in  a  cache on the client rather than in revlogs. This allows enormous
       histories to be transferred only	partially, making them easier to oper-
       ate on.

       Configs:

	  packs.maxchainlen  specifies	the maximum delta chain	length in pack
	  files

	  packs.maxpacksize specifies the maximum pack file size

	  packs.maxpackfilecount specifies the maximum number of packs in the

		 shared	cache (trees only for now)

	  remotefilelog.backgroundprefetch runs	prefetch  in  background  when
	  True

	  remotefilelog.bgprefetchrevs	specifies revisions to fetch on	commit
	  and

		 update, and on	other commands that use	them.  Different  from
		 pullprefetch.

	  remotefilelog.gcrepack  does	garbage	 collection during repack when
	  True

	  remotefilelog.nodettl	specifies maximum TTL of a node	in seconds be-
	  fore

		 it is garbage collected

	  remotefilelog.repackonhggc runs repack on hg gc when True

	  remotefilelog.prefetchdays specifies the maximum age of a commit in

		 days after which it is	no longer prefetched.

	  remotefilelog.prefetchdelay specifies	delay between background

		 prefetches  in	seconds	after operations that change the work-
		 ing copy parent

	  remotefilelog.data.gencountlimit constraints the minimum  number  of
	  data

		 pack files required to	be considered part of a	generation. In
		 particular, minimum number of packs files > gencountlimit.

	  remotefilelog.data.generations list for specifying the  lower	 bound
	  of

		 each  generation  of  the  data pack files. For example, list
		 ['100MB','1MB'] or ['1MB', '100MB'] will lead to three	gener-
		 ations: [0, 1MB), [ 1MB, 100MB) and [100MB, infinity).

	  remotefilelog.data.maxrepackpacks  the  maximum number of pack files
	  to

		 include in an incremental data	repack.

	  remotefilelog.data.repackmaxpacksize the maximum size	of a pack file
	  for

		 it to be considered for an incremental	data repack.

	  remotefilelog.data.repacksizelimit  the  maximum  total size of pack
	  files

		 to include in an incremental data repack.

	  remotefilelog.history.gencountlimit constraints the  minimum	number
	  of

		 history pack files required to	be considered part of a	gener-
		 ation.	In particular, minimum number of packs	files  >  gen-
		 countlimit.

	  remotefilelog.history.generations  list  for	specifying  the	 lower
	  bound	of

		 each generation of the	history	pack files. For	example,  list
		 [ '100MB', '1MB'] or ['1MB', '100MB'] will lead to three gen-
		 erations: [ 0,	1MB), [1MB, 100MB) and [100MB, infinity).

	  remotefilelog.history.maxrepackpacks	the  maximum  number  of  pack
	  files	to

		 include in an incremental history repack.

	  remotefilelog.history.repackmaxpacksize  the	maximum	size of	a pack
	  file

		 for it	to be considered for an	incremental history repack.

	  remotefilelog.history.repacksizelimit	the maximum total size of pack

		 files to include in an	incremental history repack.

	  remotefilelog.backgroundrepack automatically	consolidate  packs  in
	  the

		 background

	  remotefilelog.cachepath path to cache

	  remotefilelog.cachegroup if set, make	cache directory	sgid to	this

		 group

	  remotefilelog.cacheprocess binary to invoke for fetching file	data

	  remotefilelog.debug turn on remotefilelog-specific debug output

	  remotefilelog.excludepattern pattern of files	to exclude from	pulls

	  remotefilelog.includepattern pattern of files	to include in pulls

	  remotefilelog.fetchwarning: message to print when too	many

		 single-file fetches occur

	  remotefilelog.getfilesstep  number  of  files	to request in a	single
	  RPC

	  remotefilelog.getfilestype if	set to 'threaded' use threads to fetch

		 files,	otherwise use optimistic fetching

	  remotefilelog.pullprefetch revset for	selecting files	that should be

		 eagerly downloaded rather than	lazily

	  remotefilelog.reponame name of the repo. If set, used	to partition

		 data from other repos in a shared store.

	  remotefilelog.server if true,	enable server-side functionality

	  remotefilelog.servercachepath	path for caching blobs on the server

	  remotefilelog.serverexpiration number	of days	to keep	cached server

		 blobs

	  remotefilelog.validatecache if set, check cache entries for  corrup-
	  tion

		 before	returning blobs

	  remotefilelog.validatecachelog if set, check cache entries for

		 corruption before returning metadata

   Commands
   Uncategorized commands
   gc
       garbage collect the client and server filelog caches:

       hg gc [REPO...]

       garbage collect the client and server filelog caches

   prefetch
       prefetch	file revisions from the	server:

       hg prefetch [OPTIONS] [FILE...]

       Prefetchs  file revisions for the specified revs	and stores them	in the
       local remotefilelog cache.  If no rev is	specified, the default rev  is
       used  which is the union	of dot,	draft, pullprefetch and	bgprefetchrev.
       File names or patterns can be used to limit which files are downloaded.

       Return 0	on success.

       Options:

       -r,--rev	<REV[+]>
	      prefetch the specified revisions

       --repack
	      run repack after prefetch

       -b,--base <VALUE>
	      rev that is assumed to already be	local

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   repack
       hg repack [OPTIONS]

       Options:

       --background
	      run in a background process

       --incremental
	      do an incremental	repack

       --packsonly
	      only repack packs	(skip loose objects)

   verifyremotefilelog
       hg verifyremotefilelogs <directory>

       Options:

       -d, --decompress
	      decompress the filelogs first

   remotenames
	  showing remotebookmarks and remotebranches in	UI (EXPERIMENTAL)

       By default both remotebookmarks and remotebranches are turned on.  Con-
       fig knob	to control the individually are	as follows.

       Config options to tweak the default behaviour:

       remotenames.bookmarks
	      Boolean  value  to  enable or disable showing of remotebookmarks
	      (default:	True)

       remotenames.branches
	      Boolean value to enable or  disable  showing  of	remotebranches
	      (default:	True)

       remotenames.hoistedpeer
	      Name  of	the  peer whose	remotebookmarks	should be hoisted into
	      the top-level namespace (default:	'default')

   schemes
       extend schemes with shortcuts to	repository swarms

       This extension allows you to specify shortcuts for parent URLs  with  a
       lot of repositories to act like a scheme, for example:

       [schemes]
       py = http://code.python.org/hg/

       After that you can use it like:

       hg clone	py://trunk/

       Additionally  there is support for some more complex schemas, for exam-
       ple used	by Google Code:

       [schemes]
       gcode = http://{1}.googlecode.com/hg/

       The syntax is taken from	Mercurial templates, and  you  have  unlimited
       number of variables, starting with {1} and continuing with {2}, {3} and
       so on. This variables will receive parts	of URL supplied, split	by  /.
       Anything	not specified as {part}	will be	just appended to an URL.

       For convenience,	the extension adds these schemes by default:

       [schemes]
       py = http://hg.python.org/
       bb = https://bitbucket.org/
       bb+ssh =	ssh://hg@bitbucket.org/
       gcode = https://{1}.googlecode.com/hg/
       kiln = https://{1}.kilnhg.com/Repo/

       You  can	override a predefined scheme by	defining a new scheme with the
       same name.

   Commands
   Uncategorized commands
   share
       share a common history between several working directories

   Automatic Pooled Storage for	Clones
       When this extension is active, hg clone can be configured to  automati-
       cally  share/pool storage across	multiple clones. This mode effectively
       converts	hg clone to hg clone + hg share.  The benefit  of  using  this
       mode is the automatic management	of store paths and intelligent pooling
       of related repositories.

       The following share. config options influence this feature:

       share.pool

	      Filesystem path where shared repository  data  will  be  stored.
	      When  defined, hg	clone will automatically use shared repository
	      storage instead of creating a store inside each clone.

       share.poolnaming

	      How directory names in share.pool	are constructed.

	      "identity" means the name	is derived from	the first changeset in
	      the repository. In this mode, different remotes share storage if
	      their root/initial changeset is identical. In this mode, the lo-
	      cal  shared repository is	an aggregate of	all encountered	remote
	      repositories.

	      "remote" means the name is derived from the source  repository's
	      path or URL. In this mode, storage is only shared	if the path or
	      URL requested in the  hg	clone command  matches	exactly	 to  a
	      repository that was cloned before.

	      The default naming mode is "identity".

   Commands
   Repository creation
   share
       create a	new shared repository:

       hg share	[-U] [-B] SOURCE [DEST]

       Initialize  a new repository and	working	directory that shares its his-
       tory (and optionally bookmarks) with another repository.

       Note   using rollback or	extensions that	 destroy/modify	 history  (mq,
	      rebase,  etc.)  can  cause  considerable	confusion  with	shared
	      clones. In particular, if	two shared clones are both updated  to
	      the same changeset, and one of them destroys that	changeset with
	      rollback,	the other clone	will suddenly stop working: all	opera-
	      tions  will fail with "abort: working directory has unknown par-
	      ent". The	only known workaround is to use	debugsetparents	on the
	      broken clone to reset it to a changeset that still exists.

       Options:

       -U, --noupdate
	      do not create a working directory

       -B, --bookmarks
	      also share bookmarks

       --relative
	      point to source using a relative path (EXPERIMENTAL)

   Repository maintenance
   unshare
       convert a shared	repository to a	normal one:

       hg unshare

       Copy the	store data to the repo and remove the sharedpath data.

   show
       unified command to show various repository information (EXPERIMENTAL)

       This  extension	provides the hg	show command, which provides a central
       command for displaying commonly-accessed	repository data	and  views  of
       that data.

       The following config options can	influence operation.

   commands
       show.aliasprefix

	      List  of	strings	 that  will register aliases for views.	e.g. s
	      will effectively set config options alias.s<view>	= show	<view>
	      for all views. i.e. hg swork would execute hg show work.

	      Aliases that would conflict with existing	registrations will not
	      be performed.

   Commands
   Change navigation
   show
       show various repository information:

       hg show VIEW

       A requested view	of repository data is displayed.

       If no view is requested,	the list of available views is shown  and  the
       command aborts.

       Note   There  are  no backwards compatibility guarantees	for the	output
	      of this command. Output may change in any	future	Mercurial  re-
	      lease.

	      Consumers	 wanting  stable  command output should	specify	a tem-
	      plate via	-T/--template.

       List of available views:

       bookmarks   bookmarks and their associated changeset

       stack	   current line	of work

       work	   changesets that aren't finished

       Options:

       -T,--template <TEMPLATE>
	      display with template

   sparse
       allow sparse checkouts of the working directory (EXPERIMENTAL)

       (This extension is not yet protected by backwards compatibility guaran-
       tees.  Any aspect may break in future releases until this notice	is re-
       moved.)

       This extension allows the working directory to only consist of a	subset
       of files	for the	revision. This allows specific files or	directories to
       be explicitly included or excluded.  Many  repository  operations  have
       performance  proportional  to the number	of files in the	working	direc-
       tory. So	only realizing a subset	of files in the	working	directory  can
       improve performance.

   Sparse Config Files
       The  set	 of  files that	are part of a sparse checkout are defined by a
       sparse config file. The file defines 3 things: includes (files  to  in-
       clude  in  the  sparse  checkout),  excludes (files to exclude from the
       sparse checkout), and profiles (links to	other config files).

       The file	format is newline delimited. Empty lines and  lines  beginning
       with # are ignored.

       Lines  beginning	 with %include `` denote another sparse	config file to
       include.	e.g. ``%include	tests.sparse. The filename is relative to  the
       repository root.

       The  special  lines  [include] and [exclude] denote the section for in-
       cludes and excludes that	follow,	respectively. It is  illegal  to  have
       [include] after [exclude].

       Non-special lines resemble file patterns	to be added to either includes
       or excludes. The	syntax of these	lines is documented by	hg  help  pat-
       terns.	Patterns are interpreted as glob: by default and match against
       the root	of the repository.

       Exclusion patterns take precedence over inclusion patterns. So even  if
       a file is explicitly included, an [exclude] entry can remove it.

       For  example,  say you have a repository	with 3 directories, frontend/,
       backend/, and tools/. frontend/ and backend/  correspond	 to  different
       projects	 and  it  is  uncommon	for someone working on one to need the
       files for the other. But	tools/	contains  files	 shared	 between  both
       projects. Your sparse config files may resemble:

       # frontend.sparse
       frontend/**
       tools/**

       # backend.sparse
       backend/**
       tools/**

       Say the backend grows in	size. Or there's a directory with thousands of
       files you wish to exclude. You can modify the profile to	 exclude  cer-
       tain files:

       [include]
       backend/**
       tools/**

       [exclude]
       tools/tests/**

   Commands
   Uncategorized commands
   split
       command to split	a changeset into smaller ones (EXPERIMENTAL)

   Commands
   Change manipulation
   split
       split a changeset into smaller ones:

       hg split	[--no-rebase] [[-r] REV]

       Repeatedly  prompt  changes and commit message for new changesets until
       there is	nothing	left in	the original changeset.

       If --rev	was not	given, split the working directory parent.

       By default, rebase connected non-obsoleted  descendants	onto  the  new
       changeset. Use --no-rebase to avoid the rebase.

       Options:

       -r,--rev	<REV>
	      revision to split

       --rebase
	      rebase descendants after split (default: True)

       -d,--date <DATE>
	      record the specified date	as commit date

       -u,--user <USER>
	      record the specified user	as committer

   sqlitestore
       store repository	data in	SQLite (EXPERIMENTAL)

       The  sqlitestore	 extension  enables  the storage of repository data in
       SQLite.

       This extension is HIGHLY	EXPERIMENTAL. There are	NO BACKWARDS  COMPATI-
       BILITY  GUARANTEES.  This means that repositories created with this ex-
       tension may only	be usable  with	 the  exact  version  of  this	exten-
       sion/Mercurial that was used. The extension attempts to enforce this in
       order to	prevent	repository corruption.

       In addition, several features are not yet supported or have known bugs:

       o Only some data	is stored in SQLite. Changeset,	 manifest,  and	 other
	 repository data is not	yet stored in SQLite.

       o Transactions  are  not	robust.	If the process is aborted at the right
	 time during transaction close/rollback, the repository	could be in an
	 inconsistent  state.  This  problem will diminish once	all repository
	 data is tracked by SQLite.

       o Bundle	repositories do	not work (the ability to use e.g.  hg -R _bun-
	 dle-file_  log	to automatically overlay a bundle on top of the	exist-
	 ing repository).

       o Various other features	don't work.

       This extension should work for basic  clone/pull,  update,  and	commit
       workflows.   Some  history rewriting operations may fail	due to lack of
       support for bundle repositories.

       To use, activate	the extension  and  set	 the  storage.new-repo-backend
       config  option  to  sqlite to enable new	repositories to	use SQLite for
       storage.

   strip
       strip changesets	and their descendants from history

       This extension allows you to strip changesets and all their descendants
       from the	repository. See	the command help for details.

   Commands
   Repository maintenance
   strip
       strip changesets	and all	their descendants from the repository:

       hg strip	[-k] [-f] [-B bookmark]	[-r] REV...

       The  strip  command  removes the	specified changesets and all their de-
       scendants. If the working directory has uncommitted changes, the	opera-
       tion  is	 aborted  unless  the  --force flag is supplied, in which case
       changes will be discarded.

       If a parent of the working directory is stripped, then the working  di-
       rectory	will automatically be updated to the most recent available an-
       cestor of the stripped parent after the operation completes.

       Any stripped changesets are stored in .hg/strip-backup as a bundle (see
       hg  help	 bundle	and hg help unbundle). They can	be restored by running
       hg unbundle .hg/strip-backup/BUNDLE, where BUNDLE is  the  bundle  file
       created by the strip. Note that the local revision numbers will in gen-
       eral be different after the restore.

       Use the --no-backup option to discard the backup	bundle once the	opera-
       tion completes.

       Strip  is  not a	history-rewriting operation and	can be used on change-
       sets in the public phase. But if	 the  stripped	changesets  have  been
       pushed to a remote repository you will likely pull them again.

       Return 0	on success.

       Options:

       -r,--rev	<REV[+]>
	      strip  specified revision	(optional, can specify revisions with-
	      out this option)

       -f, --force
	      force removal of changesets,  discard  uncommitted  changes  (no
	      backup)

       --no-backup
	      do not save backup bundle

       --nobackup
	      do not save backup bundle	(DEPRECATED)

       -n     ignored  (DEPRECATED)

       -k, --keep
	      do not modify working directory during strip

       -B,--bookmark <BOOKMARK[+]>
	      remove revs only reachable from given bookmark

       --soft simply drop changesets from visible history (EXPERIMENTAL)

       [+] marked option can be	specified multiple times

   transplant
       command to transplant changesets	from another branch

       This extension allows you to transplant changes to another parent revi-
       sion, possibly in another repository.  The  transplant  is  done	 using
       'diff' patches.

       Transplanted  patches  are recorded in .hg/transplant/transplants, as a
       map from	a changeset hash to its	hash in	the source repository.

   Commands
   Change manipulation
   transplant
       transplant changesets from another branch:

       hg transplant [-s REPO] [-b BRANCH [-a]]	[-p REV] [-m REV] [REV]...

       Selected	changesets will	be applied on top of the current  working  di-
       rectory	with  the  log	of  the	original changeset. The	changesets are
       copied and will thus appear twice in the	history	with different identi-
       ties.

       Consider	 using	the  graft  command  if	 everything is inside the same
       repository - it will use	merges and will	usually	give a better  result.
       Use the rebase extension	if the changesets are unpublished and you want
       to move them instead of copying them.

       If --log	is specified, log messages will	have a comment appended	of the
       form:

       (transplanted from CHANGESETHASH)

       You  can	 rewrite  the changelog	message	with the --filter option.  Its
       argument	will be	invoked	with the current changelog message as  $1  and
       the patch as $2.

       --source/-s  specifies  another repository to use for selecting change-
       sets, just as if	it temporarily had been	 pulled.   If  --branch/-b  is
       specified,  these  revisions  will be used as heads when	deciding which
       changesets to transplant, just as if  only  these  revisions  had  been
       pulled.	 If  --all/-a  is specified, all the revisions up to the heads
       specified with --branch will be transplanted.

       Example:

       o transplant all	changes	up to REV on top of your current revision:

	 hg transplant --branch	REV --all

       You can optionally  mark	 selected  transplanted	 changesets  as	 merge
       changesets.  You	 will not be prompted to transplant any	ancestors of a
       merged transplant, and you can merge descendants	of them	 normally  in-
       stead of	transplanting them.

       Merge  changesets may be	transplanted directly by specifying the	proper
       parent changeset	by calling hg transplant --parent.

       If no merges or revisions are provided, hg transplant will start	an in-
       teractive changeset browser.

       If  a  changeset	 application  fails, you can fix the merge by hand and
       then resume where you left off by calling hg transplant --continue/-c.

       Options:

       -s,--source <REPO>
	      transplant changesets from REPO

       -b,--branch <REV[+]>
	      use this source changeset	as head

       -a, --all
	      pull all changesets up to	the --branch revisions

       -p,--prune <REV[+]>
	      skip over	REV

       -m,--merge <REV[+]>
	      merge at REV

       --parent	_REV_
	      parent to	choose when transplanting merge

       -e, --edit
	      invoke editor on commit messages

       --log  append transplant	info to	log message

       -c, --continue
	      continue last transplant session after fixing conflicts

       --filter	_CMD_
	      filter changesets	through	command

       [+] marked option can be	specified multiple times

   uncommit
       uncommit	part or	all of a local changeset (EXPERIMENTAL)

       This command undoes the effect of a local  commit,  returning  the  af-
       fected  files  to  their	uncommitted state. This	means that files modi-
       fied, added or removed in the changeset will be left unchanged, and  so
       will remain modified, added and removed in the working directory.

   Commands
   Change manipulation
   unamend
       undo the	most recent amend operation on a current changeset:

       hg unamend

       This  command  will  roll  back to the previous version of a changeset,
       leaving working directory in state in which it was  before  running  hg
       amend  (e.g. files modified as part of an amend will be marked as modi-
       fied hg status)

   uncommit
       uncommit	part or	all of a local changeset:

       hg uncommit [OPTION]... [FILE]...

       This command undoes the effect of a local  commit,  returning  the  af-
       fected files to their uncommitted state.	This means that	files modified
       or deleted in the changeset will	be left	unchanged, and so will	remain
       modified	in the working directory.

       If  no files are	specified, the commit will be pruned, unless --keep is
       given.

       Options:

       --keep allow an empty commit after uncommiting

       --allow-dirty-working-copy
	      allow uncommit with outstanding changes

       -I,--include <PATTERN[+]>
	      include names matching the given patterns

       -X,--exclude <PATTERN[+]>
	      exclude names matching the given patterns

       [+] marked option can be	specified multiple times

   win32mbcs
       allow the use of	MBCS paths with	problematic encodings

       Some MBCS encodings are not good	for some path operations (i.e.	split-
       ting  path, case	conversion, etc.) with its encoded bytes. We call such
       a encoding (i.e.	shift_jis and big5) as "problematic  encoding".	  This
       extension can be	used to	fix the	issue with those encodings by wrapping
       some functions to convert to Unicode string before path operation.

       This extension is useful	for:

       o Japanese Windows users	using shift_jis	encoding.

       o Chinese Windows users using big5 encoding.

       o All users who use a repository	with one of problematic	 encodings  on
	 case-insensitive file system.

       This extension is not needed for:

       o Any user who use only ASCII chars in path.

       o Any user who do not use any of	problematic encodings.

       Note that there are some	limitations on using this extension:

       o You should use	single encoding	in one repository.

       o If the	repository path	ends with 0x5c,	.hg/hgrc cannot	be read.

       o win32mbcs is not compatible with fixutf8 extension.

       By default, win32mbcs uses encoding.encoding decided by Mercurial.  You
       can specify the encoding	by config option:

       [win32mbcs]
       encoding	= sjis

       It is useful for	the users who want to commit with UTF-8	log message.

   win32text
       perform automatic newline conversion (DEPRECATED)

	  Deprecation: The win32text extension requires	each user to configure
	  the extension	again and again	for each clone since the configuration
	  is not copied	when cloning.

	  We have therefore made the eol as an alternative.  The  eol  uses  a
	  version  controlled  file  for its configuration and each clone will
	  therefore use	the right settings from	the start.

       To perform automatic newline conversion,	use:

       [extensions]
       win32text =
       [encode]
       ** = cleverencode:
       # or ** = macencode:

       [decode]
       ** = cleverdecode:
       # or ** = macdecode:

       If not doing conversion,	to make	sure you do not	commit CRLF/CR by  ac-
       cident:

       [hooks]
       pretxncommit.crlf = python:hgext.win32text.forbidcrlf
       # or pretxncommit.cr = python:hgext.win32text.forbidcr

       To  do  the same	check on a server to prevent CRLF/CR from being	pushed
       or pulled:

       [hooks]
       pretxnchangegroup.crlf =	python:hgext.win32text.forbidcrlf
       # or pretxnchangegroup.cr = python:hgext.win32text.forbidcr

   zeroconf
       discover	and advertise repositories on the local	network

       Zeroconf-enabled	repositories will be announced in  a  network  without
       the  need  to  configure	 a server or a service.	They can be discovered
       without knowing their actual IP address.

       To allow	other people to	discover your repository using run hg serve in
       your repository:

       $ cd test
       $ hg serve

       You can discover	Zeroconf-enabled repositories by running hg paths:

       $ hg paths
       zc-test = http://example.com:8000/test

FILES
       /etc/mercurial/hgrc, $HOME/.hgrc, .hg/hgrc

	      This   file  contains  defaults  and  configuration.  Values  in
	      .hg/hgrc override	those in $HOME/.hgrc, and these	override  set-
	      tings made in the	global /etc/mercurial/hgrc configuration.  See
	      hgrc(5) for details of the contents and format of	these files.

       .hgignore

	      This file	contains regular expressions (one per line)  that  de-
	      scribe file names	that should be ignored by hg. For details, see
	      hgignore(5).

       .hgsub

	      This file	defines	the  locations	of  all	 subrepositories,  and
	      tells  where the subrepository checkouts came from. For details,
	      see hg help subrepos.

       .hgsubstate

	      This file	 is  where  Mercurial  stores  all  nested  repository
	      states. NB: This file should not be edited manually.

       .hgtags

	      This file	contains changeset hash	values and text	tag names (one
	      of each separated	by spaces) that	correspond to tagged  versions
	      of  the  repository  contents. The file content is encoded using
	      UTF-8.

       .hg/last-message.txt

	      This file	is used	by hg commit to	store a	backup of  the	commit
	      message in case the commit fails.

       .hg/localtags

	      This  file can be	used to	define local tags which	are not	shared
	      among repositories. The file format is the same as for  .hgtags,
	      but it is	encoded	using the local	system encoding.

       Some  commands  (e.g.  revert) produce backup files ending in .orig, if
       the .orig file already exists and is not	tracked	by Mercurial, it  will
       be overwritten.

BUGS
       Probably	 lots,	please	post  them  to the mailing list	(see Resources
       below) when you find them.

SEE ALSO
       hgignore(5), hgrc(5)

AUTHOR
       Written by Matt Mackall <mpm@selenic.com>

RESOURCES
       Main Web	Site: https://mercurial-scm.org/

       Source code repository: https://www.mercurial-scm.org/repo/hg

       Mailing list: https://www.mercurial-scm.org/mailman/listinfo/mercurial/

COPYING
       Copyright  (C)  2005-2019  Matt	Mackall.  Free use of this software is
       granted under the terms of the GNU General Public License version 2  or
       any later version.

AUTHOR
       Matt Mackall <mpm@selenic.com>

       Organization: Mercurial

									 HG(1)

NAME | SYNOPSIS | DESCRIPTION | COMMAND ELEMENTS | OPTIONS | COMMANDS | BUNDLE FILE FORMATS | COLORIZING OUTPUTS | DATE FORMATS | DEPRECATED FEATURES | DIFF FORMATS | ENVIRONMENT VARIABLES | USING ADDITIONAL FEATURES | SPECIFYING FILE SETS | COMMAND-LINE FLAGS | GLOSSARY | SYNTAX FOR MERCURIAL IGNORE FILES | CONFIGURING HGWEB | TECHNICAL IMPLEMENTATION TOPICS | MERGE TOOLS | PAGER SUPPORT | FILE NAME PATTERNS | WORKING WITH PHASES | SPECIFYING REVISIONS | USING MERCURIAL FROM SCRIPTS AND AUTOMATION | SUBREPOSITORIES | TEMPLATE USAGE | URL PATHS | EXTENSIONS | FILES | BUGS | SEE ALSO | AUTHOR | RESOURCES | COPYING | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=hg&sektion=1&manpath=FreeBSD+12.2-RELEASE+and+Ports>

home | help