Specifying optional pathname... arguments to the status command restricts the set of changes that are visible and results in only a partial status of the workspace. Changes to files not included in the specified set of pathnames will be ignored.
From within a subdirectory of the workspace the status command
will, by default, include all changes in the workspace.
Specifying only the pathname "." will restrict status to files
changed within the current subdirectory of the workspace.
If --brief is given, the output consists of two lines per revision with the revision ID, the author, the date and the branches (separated with commas). If the --no-graph option is also given the output contains only one line per revision.
If --last=n is given, at most n log entries will be given and log will trace through history in reverse-ancestry order, from newer revisions to older revisions.
If --next=n is given, at most n log entries will be given and log will trace through history in forward-ancestry order, from older revisions to newer revisions. This is useful to review changes that will be applied to the workspace when update is run.
If --from=id is given, log starts tracing through history from the specified revisions, otherwise it starts from the base revision of your workspace. Log will stop when it reaches the end of the revision history or revisions specified by the --to option.
When tracing through history in reverse-ancestry order and --to=id is given, log will stop when it reaches the specified revisions or any of their ancestors or the end of the revision history. When tracing through history in forward-ancestry order log will stop when it reaches the specified revisions or any of their descendants or the end of the revision history.
If --revision=id is given, log will print only the specified revisions.
If both --from and --revision are given only revisions included by both options will be logged. Revisions specified by --revision that are beyond the starting points specified by --from will be excluded.
Additionally, each of the --from, --to and --revision options accept selectors, see Selectors. These can be used in various ways to log interesting revisions. For example:
$ mtn log --revision b: $ mtn log --revision today $ mtn log --revision bobwill log all revisions from the current branch, all revisions dated today and all revisions with bob as the author, respectively.
By default, the log entries for merge nodes are shown. If --no-merges is given, the log entries for these nodes will be excluded.
If --no-files is given, the log output excludes the list of files changed in each revision.
If --no-graph is given, the log output excludes the ASCII revision graph prefix on log output lines.
Specifying --diffs causes the log output to include a unified diff of the changes in each revision.
If one or more files are given, the command will only log the revisions
where those files are changed.
@
or space character and the date field
is truncated to remove the time of day.
If --revs-only is specified, each line of the file is
translated to <revision id>: <line> in the output, where <revision id>
is the revision in which that line of the file was last edited.
file
, manifest
or
revision
IDs depending on which variant is used. For
example, suppose you enter this command and get this result:
$ mtn complete revision fa36 fa36deead87811b0e15208da2853c39d2f6ebe90 fa36b76dd0139177b28b379fe1d56b22342e5306 fa36965ec190bee14c5afcac235f1b8e2239bb2a
Then monotone is telling you that there are 3 revisions it knows
about, in its database, which begin with the 4 hex digits
fa36
. This command is intended to be used by programmable
completion systems, such as those in bash and zsh.
The complete command for keys and revisions have a --verbose option. Programmable completion systems can use --verbose output to present users with additional information about each completion option.
For example, verbose output for revision
looks like this:
$ mtn complete revision 01f 01f5da490941bee1f0000f0561fc62eabfb2fa23 graydon@dub.net 2003-12-03T03:14:35 01f992577bd8bcdcade0f89e724fd5dc2d2bbe8a kinetik@orcon.nz 2005-05-11T05:19:29 01faad191d8d0474777c70b4d606782942333a78 kinetik@orcon.nz 2005-04-11T04:24:01
With one --revision option, diff will print the difference from the revision id to the current revision in the workspace. If --reverse is given, the order of the diff is reversed.
With two --revision options diff will print the difference from revision id1 to id2, ignoring any workspace.
In all cases, monotone will print a textual summary – identical to
the summary presented by mtn status – of the logical
differences between revisions in lines proceeding the diff. These
lines begin with a single hash mark #
, and should be ignored by
a program processing the diff, such as patch.
Specifying pathnames to the diff command restricts the set of changes that are visible and results in only a partial diff between two revisions. Changes to files not included in the specified set of pathnames will be ignored.
From within a subdirectory of the workspace the diff command will, by default, include all changes in the workspace. Specifying only the pathname "." will restrict diff to files changed within the current subdirectory of the workspace.
The output format of diff is controlled by the options --unified, --context, --no-show-encloser, and --external. By default, monotone uses its built-in diff algorithm to produce a listing in “unified diff” format (analogous to running the program diff -u); you can also explicitly request this with --unified. The built-in diff algorithm can also produce “context diff” format (analogous to diff -c), which you request by specifying --context. The short options that diff accepts for these modes, -u and -c, also work.
In either of these modes, monotone prints the name of the top-level code
construct that encloses each “hunk” of changes, unless suppressed with
the --no-show-encloser. The options that
diff accepts for this mode, -p and
--show-c-function, also work. Monotone finds the enclosing
construct by scanning backward from the first changed line in each
hunk for a line that matches a regular expression. The default
regular expression is correct for many programming languages. You can
adjust the expression used with the Lua hook
get_encloser_pattern
; Hooks. For the regular expression
syntax, See Regexps.
--unified requests the “unified diff” format, the default. --context requests the “context diff” format (analogous to running the program diff -c). Both of these formats are generated directly by monotone, using its built-in diff algorithm.
Sometimes, you may want more flexibility in output formats; for these
cases, you can use --external, which causes monotone to invoke
an external program to generate the actual output. By default, the
external program is diff
, and you can use the option
--diff-args to pass additional arguments controlling
formatting. The actual invocation of diff, default arguments
passed to it, and so on, are controlled by the hook
external_diff
; see Hooks for more details.
ok
or bad
For example, this command lists the certificates associated with a particular version of monotone itself, in the monotone development branch:
$ mtn list certs 4a96 mtn: expanding partial id '4a96' mtn: expanded to '4a96a230293456baa9c6e7167cafb3c5b52a8e7f' ----------------------------------------------------------------- Key : graydon@pobox.com (10b5b36b4a...) Sig : ok Name : author Value : graydon@dub.venge.net ----------------------------------------------------------------- Key : graydon@pobox.com (10b5b36b4a...) Sig : ok Name : branch Value : monotone ----------------------------------------------------------------- Key : graydon@pobox.com (10b5b36b4a...) Sig : ok Name : date Value : 2003-10-17T03:20:27 ----------------------------------------------------------------- Key : graydon@pobox.com (10b5b36b4a...) Sig : ok Name : changelog Value : 2003-10-16 graydon hoare <graydon@pobox.com> : : * sanity.hh: Add a const version of idx(). : * diff_patch.cc: Change to using idx() everywhere. : * cert.cc (find_common_ancestor): Rewrite to recursive : form, stepping over historic merges. : * tests/t_cross.at: New test for merging merges. : * testsuite.at: Call t_cross.at. :
Two or more files are considered duplicates if the sha1 hashes of their
contents are equal.
If pattern is provided, it is used as a glob to limit the keys
listed. Otherwise all keys in your database are listed.
Specifying pathnames to the list known command restricts the set of paths that are searched for manifest files. Files not included in the specified set of pathnames will not be listed.
From within a subdirectory of the workspace the list
known command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for known
files to the current subdirectory of the workspace.
Specifying pathnames to the list unknown command restricts the set of paths that are searched for unknown files. Unknown files not included in the specified set of pathnames will not be listed.
From within a subdirectory of the workspace the list
unknown command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for unknown
files to the current subdirectory of the workspace.
ignore_file
(
filename)
hook.
Specifying pathnames to the list ignored command restricts the set of paths that are searched for ignored files. Ignored files not included in the specified set of pathnames will not be listed.
From within a subdirectory of the workspace the list
ignored command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for ignored
files to the current subdirectory of the workspace.
Specifying pathnames to the list missing command restricts the set of paths that are searched for missing files. Missing files not included in the specified set of pathnames will not be listed.
From within a subdirectory of the workspace the list
missing command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for missing
files to the current subdirectory of the workspace.
Specifying pathnames to the list changed command restricts the set of paths that are checked for changes. Files not included in the specified set of pathnames will not be listed.
From within a subdirectory of the workspace the list
changed command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for known
files to the current subdirectory of the workspace.
Note that this does not show conflicts due to update commands, since in that case one revision is the workspace.