While this command places an “add” entry on your work list, it does
not immediately affect your database. When you commit your
working copy, monotone will use the work list to build a new revision,
which it will then commit to the database. The new revision will have
any added entries inserted in its manifest.
While this command places a “drop” entry on your work list, it does
not immediately affect your database. When you commit your
working copy, monotone will use the work list to build a new revision,
which it will then commit to the database. The new revision will have
any dropped entries removed from its manifest.
While this command places a “rename” entry on your work list, it
does not immediately affect your database. When you commit
your working copy, monotone will use the work list to build a new
revision, which it will then commit to the database. The new revision
will have any renamed entries in its manifest adjusted to their new
names.
For each edited file, a delta is copied into the database. Then the newly constructed manifest is recorded (as a delta) and finally the new revision. Once all these objects are recorded in you database, commit overwrites the MT/revision file with the new revision ID, and deletes the MT/work file.
Specifying pathnames to commit restricts the set of changes that are visible and results in only a partial commit of the working copy. Changes to files not included in the specified set of pathnames will be ignored and will remain in the working copy until they are included in a future commit. With a partial commit, only the relevant entries in the MT/work file will be removed and other entries will remain for future commits.
From within a subdirectory of the working copy the commit command will, by default, include all changes in the working copy. Specifying only the pathname "." will restrict commit to files changed within the current subdirectory of the working copy.
The MT/log file can be edited by the user during their daily work
to record the changes made to the working copy. When running the
commit command without a logmsg supplied, the contents
of the MT/log file will be read and passed to the Lua hook
edit_comment
as a second parameter named user_log_content.
If the commit is successful, the MT/log file is cleared of
all content making it ready for another edit/commit cycle.
The commit command also synthesizes a number of certificates, which it attaches to the new manifest version and copies into your database:
author
cert, indicating the person responsible for the changes
leading to the new revision.
branch
cert, indicating the branch the committed revision
belongs to.
date
cert, indicating when the new revision was created.
changelog
cert, containing the “log message” for these
changes. If you provided logmsg on the command line, this text
will be used, otherwise commit will run the Lua hook
edit_comment (
commentary,
user_log_content)
, which
typically invokes an external editor program, in which you can compose
and/or review your log message for the change.
If files or directories are given as arguments, only those files and directories are affected instead of the entirety of your working copy.
From within a subdirectory of the working copy the revert
command will, by default, revert all changes in the working copy.
Specifying only the pathname "." will restrict revert to files
changed within the current subdirectory of the working copy. Caution
should be used when reverting files to ensure that the correct set of
files is reverted.
With an explicit revision argument, the command uses that revision as the update target instead of finding an acceptable candidate.
The effect is always to take whatever changes you have made in the working copy, and to “transpose” them onto a new revision, using monotone's 3-way merge algorithm to achieve good results. Note that with the explicit revision argument, it is possible to update “backwards” or “sideways” in history — for example, reverting to an earlier revision, or if your branch has two heads, updating to the other. In all cases, the end result will be whatever revision you specified, with your local changes (and only your local changes) applied.