Older blog entries for conrad (starting at number 52)

Stable release maintenance with git (liboggz 1.0.2 and 1.1.1)

I recently released two new versions of liboggz, liboggz-1.0.2 and liboggz-1.1.1. These are unremarkable maintenance releases, fixing some bugs but adding no new functionality.

Last year I released liboggz-1.1.0, which introduced a new oggz_packet type. This changed some of the public API while remaining binary compatible. As this was a fairly insidious change, I decided to also keep maintaining the previous 1.0.x version so that any distributions shipping that could easily upgrade without risking breakage. I do general maintenance work and bugfixes on the 1.0.x version as much as possible, and then adapt those to 1.1.x. Luckily this is quite straightforward to keep track of in git.

After committing a change to the 1.0-stable branch I merge that into master:

$ git commit # on 1.0-stable
[1.0-stable ccd2a2f] Fix regression introduced in 8c2da1
 1 files changed, 19 insertions(+), 7 deletions(-)
$ git checkout master
Switched to branch 'master'
$ git merge 1.0-stable
Merge made by recursive.
 src/liboggz/oggz_read.c |   26 +++++++++++++++++++-------
 1 files changed, 19 insertions(+), 7 deletions(-)

As these were just maintenance releases, the commit graph produced by git lol is quite well woven:

Lightweight branching makes it easy to keep track of these changes so that simple maintenance work is isolate from other development. The upshot is that these branches are ready for release at any time; if a critical fix comes along that requires a new release, then no backporting or cherry-picking needs to be done to get the code into shape: there is always a branch in releasable state.

Of course on top of that I also have topic branches for new features under development, and I periodically merge master into those. When the new features are ready for release they can simply be merged back into the master branch and shipped, without ever getting in the way of general maintenance work.

Syndicated 2010-04-30 00:00:00 from Conrad Parker

git lola

The best tip I learned at Scott Chacon's talk at linux.conf.au 2010, Git Wrangling - Advanced Tips and Tricks was this alias:

        lol = log --graph --decorate --pretty=oneline --abbrev-commit

This provides a really nice graph of your tree, showing the branch structure of merges etc. Of course there are really nice GUI tools for showing such graphs, but the advantage of git lol is that it works on a console or over ssh, so it is useful for remote development, or native development on an embedded board.

It is even nicer when you turn syntax coloring on in git, which also has the advantage of colorizing diff output to warn about bad whitespace.

To get an idea of a whole project structure, I found myself often running git lol --all, where the --all option says to show all branches. I used that often enough that I made a new alias, git lola:

        lola = log --graph --decorate --pretty=oneline --abbrev-commit --all

which has the added bonus of making me hum Lola every single day.

So, just copy the following into ~/.gitconfig for your full color git lola action:

[alias]
        lol = log --graph --decorate --pretty=oneline --abbrev-commit
        lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
[color]
        branch = auto
        diff = auto
        interactive = auto
        status = auto