add
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.
An example showing how 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
Returns 0 if all files are successfully added.
Options:
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-S, --subrepos
recurse into subrepositories
-n, --dry-run
do not perform actions, just print output
addremove
hg addremove [OPTION]... [FILE]...
Add all new files and remove all missing files from the
repository.
New files are ignored if they match any of the patterns in
.hgignore. As with add, these changes take effect at the next
commit.
Use the -s/--similarity option to detect renamed files. This
option takes a percentage between 0 (disabled) and 100 (files
must be identical) as its parameter. With a parameter greater
than 0, this compares every removed file with every added file
and records those similar enough as renames. Detecting renamed
files this way can be expensive. After using this option, hg
status -C can be used to check which files were identified as
moved or renamed. If not specified, -s/--similarity defaults to
100 and only renames of identical files are detected.
Returns 0 if all files are successfully added.
Options:
-s, --similarity
guess renamed files by similarity (0<=s<=100)
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-n, --dry-run
do not perform actions, just print output
annotate
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.
Without the -a/--text option, annotate will avoid processing
files it detects as binary. With -a, annotate will annotate the
file anyway, although the results will probably be neither useful
nor desirable.
Returns 0 on success.
Options:
-r, --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
-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
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
aliases: blame
archive
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 (or override using -t/--type).
Examples:
• create a zip file containing the 1.0 release:
hg archive -r 1.0 project-1.0.zip
• create a tarball excluding .hg files:
hg archive project.tar.gz -X ".hg*"
Valid types are:
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
directory prefix for files in archive
-r, --rev
revision to distribute
-t, --type
type of distribution to create
-S, --subrepos
recurse into subrepositories
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
backout
hg backout [OPTION]... [-r] REV
Prepare a new changeset with the effect of REV undone in the
current working directory.
If REV is the parent of the working directory, then this new
changeset is committed automatically. Otherwise, hg needs to
merge the changes and the merged result is left uncommitted.
Note backout cannot be used to fix either an unwanted or
incorrect merge.
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.
Returns 0 on success.
Options:
--merge
merge with old dirstate parent after backout
--parent
parent to choose when backing out merge (DEPRECATED)
-r, --rev
revision to backout
-t, --tool
specify merge tool
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-m, --message
use text as commit message
-l, --logfile
read commit message from file
-d, --date
record the specified date as commit date
-u, --user
record the specified user as committer
bisect
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. Bisect will update your working directory to a
revision for testing (unless the -U/--noupdate option is
specified). Once you have performed tests, mark the working
directory as good or bad, and bisect will either 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
revision 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:
• start a bisection with known bad revision 12, and good revision
34:
hg bisect --bad 34
hg bisect --good 12
• advance the current bisection by marking current revision as
good or bad:
hg bisect --good
hg bisect --bad
• 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
• skip all revisions that do not touch directories foo or bar
hg bisect --skip '!( file("path:foo") & file("path:bar") )'
• forget the current bisection:
hg bisect --reset
• use 'make && make tests' to automatically find the first broken
revision:
hg bisect --reset
hg bisect --bad 34
hg bisect --good 12
hg bisect --command 'make && make tests'
• see all changesets whose states are already known in the
current bisection:
hg log -r "bisect(pruned)"
• see the changeset currently being bisected (especially useful
if running with -U/--noupdate):
hg log -r "bisect(current)"
• see all changesets that took part in the current bisection:
hg log -r "bisect(range)"
• with the graphlog extension, you can even get a nice graph:
hg log --graph -r "bisect(range)"
See hg help revsets for more about the bisect() keyword.
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
use command to check changeset state
-U, --noupdate
do not update to target
bookmarks
hg bookmarks [OPTIONS]... [NAME]...
Bookmarks are pointers to certain commits that move when
committing. Bookmarks are local. They can be renamed, copied and
deleted. It is possible to use hg merge NAME to merge from a
given bookmark, and hg update NAME to update to a given bookmark.
You can use hg bookmark NAME to set a bookmark on the working
directory's parent revision with the given name. If you specify a
revision using -r REV (where REV may be an existing bookmark),
the bookmark is assigned to that revision.
Bookmarks can be pushed and pulled between repositories (see hg
help push and hg help pull). This requires both the local and
remote repositories to support bookmarks. For versions prior to
1.8, this means the bookmarks extension must be enabled.
If you set a bookmark called '@', new clones of the repository
will have that revision checked out (and the bookmark made
active) by default.
With -i/--inactive, the new bookmark will not be made the active
bookmark. If -r/--rev is given, the new bookmark will not be made
active even if -i/--inactive is not given. If no NAME is given,
the current active bookmark will be marked inactive.
Options:
-f, --force
force
-r, --rev
revision
-d, --delete
delete a given bookmark
-m, --rename
rename a given bookmark
-i, --inactive
mark a bookmark inactive
aliases: bookmark
branch
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, even if it's inactive.
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
commit --close-branch to mark this branch as 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
branches
hg branches [-ac]
List the repository's named branches, indicating which ones are
inactive. If -c/--closed is specified, also list branches which
have been marked closed (see hg commit --close-branch).
If -a/--active is specified, only show active branches. A branch
is considered active if it contains repository heads.
Use the command hg update to switch to an existing branch.
Returns 0.
Options:
-a, --active
show only branches that have unmerged heads
-c, --closed
show normal and closed branches
bundle
hg bundle [-f] [-t TYPE] [-a] [-r REV]... [--base REV]... FILE [DEST]
Generate a compressed changegroup file collecting changesets not
known to be in another repository.
If you omit the destination repository, then hg assumes the
destination will have all the nodes you specify with --base
parameters. To create a bundle containing all changesets, use
-a/--all (or --base null).
You can change compression method with the -t/--type option. The
available compression methods are: none, bzip2, and gzip (by
default, bundles are compressed using bzip2).
The bundle file can then be transferred using conventional means
and applied to another repository with the unbundle or pull
command. This is useful when direct push and pull are not
available or when exporting an entire repository is undesirable.
Applying bundles preserves all changeset contents including
permissions, copy/rename information, and revision history.
Returns 0 on success, 1 if no changes found.
Options:
-f, --force
run even when the destination is unrelated
-r, --rev
a changeset intended to be added to the destination
-b, --branch
a specific branch you would like to bundle
--base a base changeset assumed to be available at the
destination
-a, --all
bundle all changesets in the repository
-t, --type
bundle compression type to use (default: bzip2)
-e, --ssh
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
cat
hg cat [OPTION]... FILE...
Print the specified files as they were at the given revision. If
no revision is given, the parent of the working directory is
used, or tip if no revision is checked out.
Output may be to a file, in which case the name of the file is
given using a format string. The formatting rules are the same as
for the export command, with the following additions:
%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
Returns 0 on success.
Options:
-o, --output
print output to file with formatted name
-r, --rev
print the given revision
--decode
apply any matching decode filter
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
clone
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
basename 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.
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. Note that
specifying a tag will include the tagged changeset but not the
changeset containing the tag.
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.
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.
In some cases, you can clone repositories and the working
directory using full hardlinks with
$ cp -al REPO REPOCLONE
This is the fastest way to clone, but it is not always safe. The
operation is not atomic (making sure REPO is not modified during
the operation is up to you) and you have to make sure your editor
breaks hardlinks (Emacs and most Linux Kernel tools do so). Also,
this is not compatible with certain extensions that place their
metadata under the .hg directory, such as mq.
Mercurial will update the working directory to the first
applicable revision 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
Examples:
• clone a remote repository to a new directory named hg/:
hg clone http://selenic.com/hg
• create a lightweight local clone:
hg clone project/ project-feature/
• clone from an absolute path on an ssh server (note
double-slash):
hg clone ssh://user@server//home/projects/alpha/
• do a high-speed clone over a LAN while checking out a specified
version:
hg clone --uncompressed http://server/repo -u 1.5
• create a repository without changesets after a particular
revision:
hg clone -r 04e544 experimental/ good/
• clone (and track) a particular named branch:
hg clone http://selenic.com/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 copy (only a
repository)
-u, --updaterev
revision, tag or branch to check out
-r, --rev
include the specified changeset
-b, --branch
clone only the specified branch
--pull use pull protocol to copy metadata
--uncompressed
use uncompressed transfer (fast over LAN)
-e, --ssh
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
commit
hg commit [OPTION]... [FILE]...
Commit changes to the given files into the repository. Unlike a
centralized 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
filenames or -I/-X filters.
If no commit message is specified, Mercurial starts your
configured editor 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 --amend flag can be used to amend the parent of the working
directory with a new commit that contains the changes in the
parent in addition 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
specified. 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.
Options:
-A, --addremove
mark new/missing files as added/removed before committing
--close-branch
mark a branch as closed, hiding it from the branch list
--amend
amend the parent of the working dir
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-m, --message
use text as commit message
-l, --logfile
read commit message from file
-d, --date
record the specified date as commit date
-u, --user
record the specified user as committer
-S, --subrepos
recurse into subrepositories
aliases: ci
copy
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
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-n, --dry-run
do not perform actions, just print output
aliases: cp
diff
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 diff may generate unexpected results for merges, as it
will default to comparing against the working directory's
first parent 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 specified, the working directory files are compared
to its 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, probably with undesirable results.
Use the -g/--git option to generate diffs in the git extended
diff format. For more information, read hg help diffs.
Examples:
• compare a file in the current working directory to its parent:
hg diff foo.c
• compare two historical versions of a directory, with rename
info:
hg diff --git -r 1.0:1.2 lib/
• get change stats relative to the last change on some date:
hg diff --stat -r "date('may 2')"
• diff all newly-added files that contain a keyword:
hg diff "set:added() and grep(GNU)"
• 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
revision
-c, --change
change made by revision
-a, --text
treat all files as text
-g, --git
use git extended diff format
--nodates
omit dates from diff headers
-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
-U, --unified
number of lines of context to show
--stat output diffstat-style summary of changes
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-S, --subrepos
recurse into subrepositories
export
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 export may generate unexpected diff output for merge
changesets, 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 format string. The formatting rules are as follows:
%%
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
Without the -a/--text option, export will avoid generating diffs
of files it detects as binary. With -a, export will generate a
diff anyway, probably with undesirable results.
Use the -g/--git option to generate diffs in the git extended
diff format. See hg help diffs for more information.
With the --switch-parent option, the diff will be against the
second parent. It can be useful to review a merge.
Examples:
• use export and import to transplant a bugfix to the current
branch:
hg export -r 9353 | hg import -
• export all the changesets between two revisions to a file with
rename information:
hg export --git -r 123:150 > changes.txt
• split outgoing changes into a series of patches with
descriptive names:
hg export -r "outgoing()" -o "%n-%m.patch"
Returns 0 on success.
Options:
-o, --output
print output to file with formatted name
--switch-parent
diff against the second parent
-r, --rev
revisions to export
-a, --text
treat all files as text
-g, --git
use git extended diff format
--nodates
omit dates from diff headers
forget
hg forget [OPTION]... FILE...
Mark the specified files so they will no longer be tracked after
the next commit.
This only removes files from the current branch, not from the
entire project history, and it does not delete them from the
working directory.
To undo a forget before the next commit, see hg add.
Examples:
• forget newly-added binary files:
hg forget "set:added() and binary()"
• forget files that would be excluded by .hgignore:
hg forget "set:hgignore()"
Returns 0 on success.
Options:
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
graft
hg graft [OPTION]... [-r] 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
already 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 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/--continue option.
Note The -c/--continue option does not reapply earlier options.
Examples:
• copy a single change to the stable branch and edit its
description:
hg update stable
hg graft --edit 9393
• graft a range of changesets with one exception, updating dates:
hg graft -D "2085::2093 and not 2091"
• continue a graft after resolving conflicts:
hg graft -c
• show the source of a grafted changeset:
hg log --debug -r tip
Returns 0 on successful completion.
Options:
-r, --rev
revisions to graft
-c, --continue
resume interrupted graft
-e, --edit
invoke editor on commit messages
--log append graft info to log message
-D, --currentdate
record the current date as commit date
-U, --currentuser
record the current user as committer
-d, --date
record the specified date as commit date
-u, --user
record the specified user as committer
-t, --tool
specify merge tool
-n, --dry-run
do not perform actions, just print output
grep
hg grep [OPTION]... PATTERN [FILE]...
Search revisions of files for a regular expression.
This command behaves differently than Unix grep. It only accepts
Python/Perl regexps. It searches repository history, not the
working directory. It always prints the revision number in which
a match appears.
By default, grep only prints output for the first revision of a
file in which it finds a match. To get it to print every revision
that contains a change in match status ("-" for a match that
becomes a non-match, or "+" for a non-match that becomes a
match), use the --all flag.
Returns 0 if a match is found, 1 otherwise.
Options:
-0, --print0
end fields with NUL
--all print all revisions that match
-a, --text
treat all files as text
-f, --follow
follow changeset history, or file history across copies
and renames
-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
only search files changed within revision range
-u, --user
list the author (long with -v)
-d, --date
list the date (short with -q)
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
heads
hg heads [-ct] [-r STARTREV] [REV]...
With no arguments, show all repository branch heads.
Repository "heads" are changesets with no child changesets. They
are where development generally takes place and are the usual
targets for update and merge operations. Branch heads are
changesets that have no child changeset on the same branch.
If one or more REVs are given, only branch heads on the branches
associated with the specified changesets are shown. This means
that you can use hg heads foo to see the heads on a branch named
foo.
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 changesets without children will be shown.
Returns 0 if matching heads are found, 1 if not.
Options:
-r, --rev
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
display using template map file
--template
display with template
help
hg help [-ec] [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
identify
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.
Specifying a path to a repository root or Mercurial bundle will
cause lookup to operate on that repository/bundle.
Examples:
• generate a build identifier for the working directory:
hg id --id > build-id.dat
• find the revision corresponding to a tag:
hg id -n -r 1.3
• check the most recent revision of a remote repository:
hg id -r tip http://selenic.com/hg/
Returns 0 if successful.
Options:
-r, --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
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
aliases: id
import
hg import [OPTION]... PATCH...
Import a list of patches and commit them individually (unless
--no-commit is specified).
If there are outstanding changes in the working directory, import
will abort unless given the -f/--force flag.
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 commit
message.
If the imported patch was generated by hg export, user and
description from patch override values from message headers and
body. Values given on command line with -m/--message and
-u/--user override these.
If --exact is specified, import will set the working directory to
the parent of each patch before applying it, and will abort if
the resulting changeset has a different ID than the one recorded
in the patch. This may happen due to character set problems or
other deficiencies in the text patch format.
Use --bypass to apply and commit patches directly to the
repository, not touching the working directory. Without --exact,
patches will be applied on top of the working directory parent
revision.
With -s/--similarity, hg will attempt to discover renames and
copies in the patch in the same way as hg addremove.
To read a patch from standard input, use "-" as the patch name.
If a URL is specified, the patch will be downloaded from it. See
hg help dates for a list of formats valid for -d/--date.
Examples:
• import a traditional patch from a website and detect renames:
hg import -s 80 http://example.com/bugfix.patch
• import a changeset from an hgweb server:
hg import http://www.selenic.com/hg/rev/5ca8c111e9aa
• import all the patches in an Unix-style mbox:
hg import incoming-patches.mbox
• attempt to exactly restore an exported changeset (not always
possible):
hg import --exact proposed-fix.patch
Returns 0 on success.
Options:
-p, --strip
directory strip option for patch. This has the same
meaning as the corresponding patch option (default: 1)
-b, --base
base path (DEPRECATED)
-e, --edit
invoke editor on commit messages
-f, --force
skip check for outstanding uncommitted changes
--no-commit
don't commit, just update the working directory
--bypass
apply patch without touching the working directory
--exact
apply patch to the nodes from which it was generated
--import-branch
use any branch information in patch (implied by --exact)
-m, --message
use text as commit message
-l, --logfile
read commit message from file
-d, --date
record the specified date as commit date
-u, --user
record the specified user as committer
-s, --similarity
guess renamed files by similarity (0<=s<=100)
aliases: patch
incoming
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 if a pull at the time you issued this command.
For remote repository, using --bundle avoids downloading the
changesets twice if the incoming is followed by a pull.
See pull for valid source format details.
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 to store the bundles into
-r, --rev
a remote changeset intended to be added
-B, --bookmarks
compare bookmarks
-b, --branch
a specific branch you would like to pull
-p, --patch
show patch
-g, --git
use git extended diff format
-l, --limit
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
display using template map file
--template
display with template
-e, --ssh
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
-S, --subrepos
recurse into subrepositories
aliases: in
init
hg init [-e CMD] [--remotecmd CMD] [DEST]
Initialize a new repository in the given directory. If the given
directory 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
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
locate
hg locate [OPTION]... [PATTERN]...
Print files under Mercurial control in the working directory
whose names match the given patterns.
By default, this command searches all directories in the working
directory. To search just the current directory and its
subdirectories, use "--include .".
If no patterns are given to match, this command prints the names
of all files under Mercurial control in the working directory.
If you want to feed the output of this command into the "xargs"
command, use the -0 option to both this command and "xargs". This
will avoid the problem of "xargs" treating single filenames that
contain whitespace as multiple filenames.
Returns 0 if a match is found, 1 otherwise.
Options:
-r, --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
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
log
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 or descendants 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 commit. When the -v/--verbose switch is used, the list of
changed files and full commit message are shown.
Note log -p/--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, log FILE may omit duplicate
changes made on branches and will not show deletions. To
see all changes including duplicates and deletions, use
the --removed switch.
Some examples:
• changesets with full descriptions and file lists:
hg log -v
• changesets ancestral to the working directory:
hg log -f
• last 10 commits on the current branch:
hg log -l 10 -b .
• changesets showing all modifications of a file, including
removals:
hg log --removed file.c
• all changesets that touch a directory, with diffs, excluding
merges:
hg log -Mp lib/
• all revision numbers that match a keyword:
hg log -k bug --template "{rev}\n"
• check if a given changeset is included is a tagged release:
hg log -r "a21ccf and ancestor(1.9)"
• find all changesets by some user in a date range:
hg log -k alice -d "may 2008 to jul 2008"
• summary of all changesets after the last tag:
hg log -r "last(tagged())::" --template "{desc|firstline}\n"
See hg help dates for a list of formats valid for -d/--date.
See hg help revisions and hg help revsets for more about
specifying revisions.
See hg help templates for more about pre-packaged styles and
specifying custom templates.
Returns 0 on success.
Options:
-f, --follow
follow changeset history, or file history across copies
and renames
--follow-first
only follow the first parent of merge changesets
(DEPRECATED)
-d, --date
show revisions matching date spec
-C, --copies
show copied files
-k, --keyword
do case-insensitive search for a given text
-r, --rev
show the specified revision or range
--removed
include revisions where files were removed
-m, --only-merges
show only merges (DEPRECATED)
-u, --user
revisions committed by user
--only-branch
show only changesets within the given named branch
(DEPRECATED)
-b, --branch
show changesets within the given named branch
-P, --prune
do not display revision or any of its ancestors
-p, --patch
show patch
-g, --git
use git extended diff format
-l, --limit
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
display using template map file
--template
display with template
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
aliases: history
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
revision to display
--all list files from all revisions
merge
hg merge [-P] [-f] [[-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 with must be provided.
hg resolve must be used to resolve unresolved files.
To undo an uncommitted merge, use hg update --clean . 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 with outstanding changes
-r, --rev
revision to merge
-P, --preview
review revisions to merge (no merge is performed)
-t, --tool
specify merge tool
outgoing
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.
Returns 0 if there are outgoing changes, 1 otherwise.
Options:
-f, --force
run even when the destination is unrelated
-r, --rev
a changeset intended to be included in the destination
-n, --newest-first
show newest record first
-B, --bookmarks
compare bookmarks
-b, --branch
a specific branch you would like to push
-p, --patch
show patch
-g, --git
use git extended diff format
-l, --limit
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
display using template map file
--template
display with template
-e, --ssh
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
-S, --subrepos
recurse into subrepositories
aliases: out
parents
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 (before the working directory revision or the
argument to --rev if given) is printed.
Returns 0 on success.
Options:
-r, --rev
show parents of the specified revision
--style
display using template map file
--template
display with template
paths
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 that default and default-push apply to
all inbound (e.g. hg incoming) and outbound (e.g. hg outgoing,
hg email and hg bundle) operations.
See hg help urls for more information.
Returns 0 on success.
phase
hg phase [-p|-d|-s] [-f] [-r] REV...
With no argument, show the phase name of specified revisions.
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 changeset
from a lower phase to an higher phase. Phases are ordered as
follows:
public < draft < secret
Return 0 on success, 1 if no phases were changed or some could
not be changed.
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
target revision
pull
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 specified). By default, this does not update the
copy of the project in the working directory.
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.
Returns 0 on success, 1 if an update had unresolved files.
Options:
-u, --update
update to new branch head if changesets were pulled
-f, --force
run even when remote repository is unrelated
-r, --rev
a remote changeset intended to be added
-B, --bookmark
bookmark to pull
-b, --branch
a specific branch you would like to pull
-e, --ssh
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
push
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
destination, 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.
Use -f/--force to override the default behavior and push all
changesets on all branches.
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
ancestors, and the bookmark will be pushed to the remote
repository.
Please see hg help urls for important details about ssh:// URLs.
If DESTINATION is omitted, a default path will be used.
Returns 0 if push was successful, 1 if nothing to push.
Options:
-f, --force
force push
-r, --rev
a changeset intended to be included in the destination
-B, --bookmark
bookmark to push
-b, --branch
a specific branch you would like to push
--new-branch
allow pushing a new branch
-e, --ssh
specify ssh command to use
--remotecmd
specify hg command to run on the remote side
--insecure
do not verify server certificate (ignoring web.cacerts
config)
recover
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.
remove
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):
┌─────┬───┬────┬────┬───┐
│ │ │ │ │ │
├─────┼───┼────┼────┼───┤
│none │ W │ RD │ W │ R │
├─────┼───┼────┼────┼───┤
│-f │ R │ RD │ RD │ R │
├─────┼───┼────┼────┼───┤
│-A │ W │ W │ W │ R │
├─────┼───┼────┼────┼───┤
│-Af │ R │ R │ R │ R │
└─────┴───┴────┴────┴───┘
Note that remove never deletes files in Added [A] state from the
working directory, not even if option --force is specified.
Returns 0 on success, 1 if any warnings encountered.
Options:
-A, --after
record delete for missing files
-f, --force
remove (and delete) file even if added or modified
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
aliases: rm
rename
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 copy over an existing managed file
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-n, --dry-run
do not perform actions, just print output
aliases: move mv
resolve
hg resolve [OPTION]... [FILE]...
Merges with unresolved conflicts are often the result of
non-interactive merging using the internal:merge configuration
setting, or a command-line merge tool like diff3. The resolve
command is used to manage the files involved in a merge, after hg
merge has been run, and before hg commit is run (i.e. the working
directory must have two parents). See hg help merge-tools for
information on configuring merge tools.
The resolve command can be used in the following ways:
• hg resolve [--tool TOOL] FILE...: attempt to re-merge the
specified files, discarding any previous merge attempts.
Re-merging is not performed for files already marked as
resolved. Use --all/-a to select all unresolved files. --tool
can be used to specify the merge tool used for the given files.
It overrides the HGMERGE environment variable and your
configuration files. Previous file contents are saved with a
.orig suffix.
• hg resolve -m [FILE]: mark a file as having been resolved (e.g.
after having manually fixed-up the files). The default is to
mark all unresolved files.
• hg resolve -u [FILE]...: mark a file as unresolved. The default
is to mark all resolved files.
• hg resolve -l: list files which had or still have conflicts.
In the printed list, U = unresolved and R = resolved.
Note that 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.
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
-t, --tool
specify merge tool
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
revert
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 update --clean ..
With no revision specified, revert the specified files or
directories to the contents they had in the parent of the working
directory. This restores the contents of files to an unmodified
state and unschedules adds, removes, copies, and renames. If the
working directory has two parents, you must explicitly specify a
revision.
Using the -r/--rev or -d/--date options, revert the given files
or directories to their states as of a specific revision. Because
revert does not change the working directory parents, this will
cause these files to appear modified. This can be helpful to
"back out" some or all of an earlier change. See hg backout for a
related method.
Modified files are saved with a .orig suffix before reverting.
To disable these backups, use --no-backup.
See hg help dates for a list of formats valid for -d/--date.
Returns 0 on success.
Options:
-a, --all
revert all changes when no arguments given
-d, --date
tipmost revision matching date
-r, --rev
revert to the specified revision
-C, --no-backup
do not save backup copies of files
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-n, --dry-run
do not perform actions, just print output
rollback
hg rollback
This command should be used with care. There is only one level of
rollback, and there is no way to undo a rollback. It will also
restore the dirstate at the time of the last transaction, losing
any dirstate changes since that time. This command does not alter
the working directory.
Transactions are used to encapsulate the effects of all commands
that create new changesets or propagate existing changesets into
a repository.
For example, the following commands are transactional, and their
effects can be rolled back:
• commit
• import
• pull
• push (with this repository as the destination)
• unbundle
To avoid permanent data loss, rollback will refuse to rollback a
commit transaction if it isn't checked out. Use --force to
override this protection.
This command is not intended for use on public repositories. Once
changes are visible for pull by other users, rolling a
transaction back locally is ineffective (someone else may already
have pulled the changes). Furthermore, a race is possible with
readers of the repository; for example an in-progress pull from
the repository may fail if a rollback is performed.
Returns 0 on success, 1 if no rollback data is available.
Options:
-n, --dry-run
do not perform actions, just print output
-f, --force
ignore safety measures
root
hg root
Print the root directory of the current repository.
Returns 0 on success.
serve
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 everybody 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
name of access log file to write to
-d, --daemon
run server in background
--daemon-pipefds
used internally by daemon mode
-E, --errorlog
name of error log file to write to
-p, --port
port to listen on (default: 8000)
-a, --address
address to listen on (default: all interfaces)
--prefix
prefix path to serve from (default: server root)
-n, --name
name to show in web pages (default: working directory)
--web-conf
name of the hgweb config file (see "hg help hgweb")
--webdir-conf
name of the hgweb config file (DEPRECATED)
--pid-file
name of file to write process ID to
--stdio
for remote clients
--cmdserver
for remote clients
-t, --templates
web templates to use
--style
template style to use
-6, --ipv6
use IPv6 in addition to IPv4
--certificate
SSL certificate file
showconfig
hg showconfig [-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.
With --debug, the source (filename and line number) is printed
for each config item.
Returns 0 on success.
Options:
-u, --untrusted
show untrusted configuration options
aliases: debugconfig
status
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 status may appear to disagree with diff if permissions
have changed or a merge has occurred. The standard diff
format does not report permission changes and diff only
reports changes relative to one merge parent.
If one revision is given, it is used as the base revision. If
two revisions are given, the differences between them are shown.
The --change option can also be used as a shortcut to list the
changed files of a revision from its first parent.
The codes used to show the status of files are:
M = modified
A = added
R = removed
C = clean
! = missing (deleted by non-hg command, but still tracked)
? = not tracked
I = ignored
= origin of the previous file listed as A (added)
Examples:
• show changes in the working directory relative to a changeset:
hg status --rev 9353
• show all changes including copies in an existing changeset:
hg status --copies --change 9353
• get a NUL separated list of added files, suitable for xargs:
hg status -an0
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
-C, --copies
show source of copied files
-0, --print0
end filenames with NUL, for use with xargs
--rev show difference from revision
--change
list the changed files of a revision
-I, --include
include names matching the given patterns
-X, --exclude
exclude names matching the given patterns
-S, --subrepos
recurse into subrepositories
aliases: st
summary
hg summary [--remote]
This generates a brief summary of the working directory state,
including parents, branch, commit status, and available updates.
With the --remote option, this will check the default paths for
incoming and outgoing changes. This can be time-consuming.
Returns 0 on success.
Options:
--remote
check for push and pull
aliases: sum
tag
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, or tip if no revision is checked out.
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
revision to tag
--remove
remove a tag
-e, --edit
edit commit message
-m, --message
use <text> as commit message
-d, --date
record the specified date as commit date
-u, --user
record the specified user as committer
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.
Returns 0 on success.
tip
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.
Returns 0 on success.
Options:
-p, --patch
show patch
-g, --git
use git extended diff format
--style
display using template map file
--template
display with template
unbundle
hg unbundle [-u] FILE...
Apply one or more compressed changegroup files generated by the
bundle command.
Returns 0 on success, 1 if an update has unresolved files.
Options:
-u, --update
update to new branch head if changesets were unbundled
update
hg update [-c] [-C] [-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 current bookmark (see hg help
bookmarks).
Update sets the working directory's parent revision to the
specified changeset (see hg help parents).
If the changeset is not a descendant or ancestor of the working
directory's parent, the update is aborted. With the -c/--check
option, the working directory is checked for uncommitted changes;
if none are found, the working directory is updated to the
specified changeset.
The following rules apply when the working directory contains
uncommitted changes:
1. If neither -c/--check nor -C/--clean is specified, and if the
requested changeset is an ancestor or descendant of the
working directory's parent, the uncommitted changes are merged
into the requested changeset and the merged result is left
uncommitted. If the requested changeset is not an ancestor or
descendant (that is, it is on another branch), the update is
aborted and the uncommitted changes are preserved.
2. With the -c/--check option, the update is aborted and the
uncommitted changes are preserved.
3. 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
update --clean ..
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
update across branches if no uncommitted changes
-d, --date
tipmost revision matching date
-r, --rev
revision
aliases: up checkout co
verify
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 http://mercurial.selenic.com/wiki/RepositoryCorruption
for more information about recovery from corruption of the
repository.
Returns 0 on success, 1 if errors are encountered.
version
hg version
output version and copyright information
