ils on how to specify X and Y.
      Some common examples are given below::

        -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

      When logging a range of revisions using -rX..Y, log starts at
      revision Y and searches back in history through the primary
      ("left-hand") parents until it finds X. When logging just the
      top level (using -n1), an error is reported if X is not found
      along the way. If multi-level logging is used (-n0), X may be
      a nested merge revision and the log will be truncated accordingly.

    :Path filtering:

      If parameters are given and the first one is not a branch, the log
      will be filtered to show only those revisions that changed the
      nominated files or directories.

      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.

      Historical context is also important when interpreting pathnames of
      renamed files/directories. Consider the following example:

      * revision 1: add tutorial.txt
      * revision 2: modify tutorial.txt
      * revision 3: rename tutorial.txt to guide.txt; add tutorial.txt

      In this case:

      * ``brz log guide.txt`` will log the file added in revision 1

      * ``brz log tutorial.txt`` will log the new file added in revision 3

      * ``brz log -r2 -p tutorial.txt`` will show the changes made to
        the original file in revision 2.

      * ``brz log -r2 -p guide.txt`` will display an error message as there
        was no file called guide.txt in revision 2.

      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).

    :Other filtering:

      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.

    :Tips & tricks:

      GUI tools and IDEs are often better at exploring history than command
      line tools: you may prefer qlog from qbzr, or the Loggerhead web
      interface.  See the Breezy
      Plugin Guide <https://www.breezy-vcs.org/doc/plugins/en/> and
      <http://wiki.breezy-vcs.org/IDEIntegration>.

      You may find it useful to add the aliases below to ``breezy.conf``::

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

      ``brz tip`` will then show the latest revision while ``brz top``
      will show the last 10 mainline revisions. To see the details of a
      particular revision X,  ``brz show -rX``.

      If you are interested in looking deeper into a particular merge X,
      use ``brz log -n0 -rX``.

      ``brz 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.

      brz has a generic full-text matching plugin, brz-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.

      When exploring non-mainline history on large projects with deep
      history, the performance of log can be greatly improved by installing
      the historycache plugin. This plugin buffers historical information
      trading disk space for faster speed.
    r…