• Choose a category
• All
• Classic-Fiction

The description of the problem is not always clear (as in this case), but even when it is cryptic, it is almost always trivial to visually inspect the offending line in the style file and see what is wrong.

Uniquely Identifying a Repository

If you would like to be able to identify a Mercurial repository fairly uniquely using a short string as an identifier, you can use the first revision in the repository.

$ hg log -r0 --template '{node}'

c190a4d6b8ed776cf4103dd4ed9260cc3b79ba27

This is likely to be unique, and so it is useful in many cases. There are a few caveats:

It will not work in a completely empty repository, because such a repository does not have a revision zero.

Neither will it work in the (extremely rare) case where a repository is a merge of two or more formerly independent repositories, and you still have those repositories around.

Here are some uses to which you could put this identifier:

As a key into a table for a database that manages repositories on a server.

As half of a {repository ID, revision ID} tuple. Save this information away when you run an automated build or other activity, so that you can “replay” the build later if necessary.

Listing Files on Multiple Lines

Suppose we want to list the files changed by a changeset, one per line, with a little indentation before each filename.

$ cat > multiline << EOF

> changeset = "Changed in {node|short}:\n{files}"

> file = " {file}\n"

> EOF

$ hg log --style multiline

Changed in f55a274d193b:

.bashrc

.hgrc

test.c

Mimicking Subversion’s Output

Let’s try to emulate the default output format used by another revision control tool, Subversion.

$ svn log -r9653

------------------------------------------------------------------------

r9653 | sean.hefty | 2006-09-27 14:39:55 -0700 (Wed, 27 Sep 2006) | 5 lines

On reporting a route error, also include the status for the error,

rather than indicating a status of 0 when an error has occurred.

Signed-off-by: Sean Hefty

------------------------------------------------------------------------

Since Subversion’s output style is fairly simple, it is easy to copy-and-paste a hunk of its output into a file, and replace the text produced above by Subversion with the template values we’d like to see expanded.

$ cat svn.template

r{rev} | {author|user} | {date|isodate} ({date|rfc822date})

{desc|strip|fill76}

------------------------------------------------------------------------

There are a few small ways in which this template deviates from the output produced by Subversion:

Subversion prints a “readable” date (the Wed, 27 Sep 2006 in the example output above) in parentheses. Mercurial’s templating engine does not provide a way to display a date in this format without also printing the time and timezone.

We emulate Subversion’s printing of separator lines full of - characters by ending the template with such a line. We use the templating engine’s header keyword to print a separator line as the first line of output (see below), thus achieving similar output to Subversion.

Subversion’s output includes a count in the header of the number of lines in the commit message. We cannot replicate this in Mercurial; the templating engine does not currently provide a filter that counts the number of lines the template generates.

It took me no more than a minute or two of work to replace literal text from an example of Subversion’s output with some keywords and filters to give the template above. The style file simply refers to the template.

$ cat svn.style

header = '-----------------------------------------------------------------------\n\n'

changeset = svn.template

We could have included the text of the template file directly in the style file by enclosing it in quotes and replacing the newlines with \n sequences, but it would have made the style file too difficult to read. Readability is a good guide when you’re trying to decide whether some text belongs in a style file, or in a template file that the style file