Translations by Maida

If no arguments are given, all changes for the current tree are listed. If files are given, only the changes in those files are listed. Remote and multiple branches can be compared by using the --old and --new options. If not provided, the default for both is derived from the first argument, if any, or the current tree if no arguments are given.

Note that when using the -r argument with a range of revisions, the differences are computed between the two specified revisions. That is, the command does not show the changes introduced by the first revision in the range. This differs from the interpretation of revision ranges used by "bzr log" which includes the first revision in the range.

log is bzr's default tool for exploring the history of a branch. The branch to use is taken from the first parameter. If no parameters are given, the branch containing the working directory is logged. Here are some simple examples::

bzr log log the current branch bzr log foo.py log a file in its branch bzr log http://server/branch log a branch on a server

The filtering, ordering and information shown for each revision can be controlled as explained below. By default, all revisions are shown sorted (topologically) so that newer revisions appear before older ones and descendants always appear before ancestors. If displayed, merged revisions are shown indented under the revision in which they were merged.

Status summaries are shown using status flags like A, M, etc. To see the changes explained using words like ``added`` and ``modified`` instead, use the -vv option.

To display revisions from oldest to newest, use the --forward option. In most cases, using this option will have little impact on the total time taken to produce a log, though --forward does not incrementally display revisions like --reverse does when it can.

-r-1 show just the tip -r-10.. show the last 10 mainline revisions -rsubmit:.. show what's new on this branch -rancestor:path.. show changes since the common ancestor of this branch and the one at location path -rdate:yesterday.. show changes since yesterday

Filenames are interpreted within their historical context. To log a deleted file, specify a revision range so that the file existed at the end or start of the range.

Renames are always followed by log. By design, there is no need to explicitly ask for this (and no way to stop logging a file back until it was last renamed).

The --match option can be used for finding revisions that match a regular expression in a commit message, committer, author or bug. Specifying the option several times will match any of the supplied expressions. --match-author, --match-bugs, --match-committer and --match-message can be used to only match a specific field.

GUI tools and IDEs are often better at exploring history than command line tools: you may prefer qlog or viz from qbzr or bzr-gtk, the bzr-explorer shell, or the Loggerhead web interface. See the Plugin Guide <http://doc.bazaar.canonical.com/plugins/en/> and <http://wiki.bazaar.canonical.com/IDEIntegration>.

[ALIASES] tip = log -r-1 top = log -l10 --line show = log -v -p

``bzr log -v`` on a branch with lots of history is currently very slow. A fix for this issue is currently under development. With or without that fix, it is recommended that a revision range be given when using the -v option.

bzr has a generic full-text matching plugin, bzr-search, that can be used to find revisions matching user names, commit messages, etc. Among other features, this plugin can find all revisions containing a list of words but not others.

If a .bzrignore file does not exist, the ignore command will create one and add the specified files or patterns to the newly created file. The ignore command will also automatically add the .bzrignore file to be versioned. Creating a .bzrignore file without the use of the ignore command will require an explicit add command.

To remove patterns from the ignore list, edit the .bzrignore file. After adding, editing or deleting that file either indirectly by using this command or directly by using an editor, be sure to commit it.

Bazaar also supports a global ignore file ~/.bazaar/ignore. On Windows the global ignore file can be found in the application data directory as C:\Documents and Settings\<user>\Application Data\Bazaar\2.0\ignore. Global ignores are not touched by this command. The global ignore file can be edited directly using an editor.

Patterns prefixed with '!' are exceptions to ignore patterns and take precedence over regular ignores. Such exceptions are used to specify files that should be versioned which would otherwise be ignored.

Warning: the following files are version controlled and match your ignore pattern: %s These files will continue to be version controlled unless you 'bzr remove' them.

Format may be an "exporter" name, such as tar, tgz, tbz2. If none is given, try to find the format with the extension. If no extension is found exports to a directory (equivalent to --format=dir).

If root is supplied, it will be used as the root directory inside container formats (tar, zip, etc). If it is not supplied it will default to the exported filename. The root option has no effect for 'dir' format.

Export the working tree contents rather than that of the last revision.

Write the contents of a file as of a given revision to standard output.

Note: Take care to redirect standard output when using this command on a binary file.

An explanatory message needs to be given for each commit. This is often done by using the --message option (getting the message from the command line) or by using the --file option (getting the message from a file). If neither of these options is given, an editor is opened for the user to enter the message. To see the changed files in the boilerplate text loaded into the editor, use the --show-diff option.

If selected files are specified, only changes to those files are committed. If a directory is specified then the directory and everything within it is committed.

When excludes are given, they take precedence over selected files. For example, to commit only changes within foo, but not changes within foo/bar::

If the author of the change is not the same person as the committer, you can specify the author's name using the --author option. The name should be in the same format as a committer-id, e.g. "John Doe <jdoe@example.com>". If there is more than one author of the change you can specify the option multiple times, once for each author.

A common mistake is to forget to add a new file or directory before running the commit command. The --strict option checks for unknown files and aborts the commit if any are found. More advanced pre-commit checks can be implemented by defining hooks. See ``bzr help hooks`` for details.

If you accidentially commit the wrong changes or make a spelling mistake in the commit message say, you can use the uncommit command to undo it. See ``bzr help uncommit`` for details.

Hooks can also be configured to run after a commit. This allows you to trigger updates to external systems like bug trackers. The --fixes option can be used to record the association between a revision and one or more bugs. See ``bzr help bugs`` for details.