Ah, the world of changes. Always changing things are. And keeping track of changes can be quite the challenge. Thankfully we have version control systems to make the chore a bit easier. But review these changes and we find our output options limited. That's were VCLog comes in. Learn More...
Copyright (c) 2009 Rubyworks. All Rights Reserved.
How about a Change Log in glorious technicolor!
Or a Release History to make you feel like a schoold girl with a box of crayons.
VCLog can provide a changelogs in a variety of uniform formats for different SCMs. If we ask vclog for help will see it's commandline interface is fairly self-explanatory.
$ vclog help Usage: vclog [TYPE] [OPTIONS] OUTPUT TYPE: (choose one) changelog display a Change Log history display a Release History version display the current tag version bump display next reasonable version list display format options help show help information
Help for generating a Change Log looks like this:
$ vclog log --help Usage: vclog [changelog | log] [options] Print a Change Log. OUTPUT OPTIONS: (use varies with format) -f, --format FORMAT output format --styleprovide a stylesheet URI (css or xsl) for HTML or XML format -t, --title TITLE document title -d, --detail provide details --id include revision id -l, --level NUMBER lowest level of commit to display [0] SYSTEM OPTIONS: --debug show debugging information -h, --help display this help information
Without any format selected, vclog
will use the ANSI-colored GNU-like format.
Here is an example of the non-colored GNU format.
$ vclog -f gnu 2009-10-23 7rans* update pom metadata 2009-10-12 7rans * changed licenses to MIT * fixed typo in LICENSE * contact suffices * fixed syckle config * update tasks and metadata 2009-10-06 7rans * reap became syckle 2009-08-17 proutils * first commit
One of the coolest features of vclog is it's ability to lookup tags and build a Release History file.
$ vclog rel -f rdoc -v 1.1.0 == 1.1.0 / 2009-10-23 * 1 General Enhancements * update pom metadata == 1.0.0 / 2009-10-13 * 6 General Enhancements * reap became syckle * update tasks and metadata * fixed syckle config * contact suffices * fixed typo in LICENSE * changed licenses to MIT == 0.1.0 / 2009-08-17 * 1 General Enhancements * first commit
A variety of formats are available for Change Logs and Release Histories, Here are examples of VCLog's own.
Finally, VCLog recognizes commit types through a set of heuristics. You can define you own set by creating a `vclog` block in a config.rb
file or .config.rb
. See VCLog's own file for an example.
By default VCLog heuristics recognize a single-word marker placed at the beginning of the commit message separated by a colon, or placed at the at the end of a commit messages wrapped in square brackets. It you utilize these, e.g. git commit -m "bug: fixed foo issue"
or git commit -m "fixed foo issue [bug]"
, then you can sort the changelog output by type. You can see this already in the previous examples. Out of thebox VCLog recognizes major
, minor
, bug
, doc
and admin
. Any other label is treated verbatim, e.g. doozy
would show up as "Doozy Enhancements
".
Commit types can be a very useful way to categorize your commits and thus present more readable changelogs. Wouldn't it be nice if SCMs supported commit types directly?
VCLog's code repository is hosted on GitHub.
If you have a feauture question, or a problem to report please do not hesitate to sumbit an issue report.
Our development Logs may also be helpful.