In March, the founder of Hacker Monthly magazine ("The Best of Hacker News, in Print") contacted me to ask for permission to reprint my article in the next issue. I got a print copy and a year's digital subscription. I had only heard of the magazine in passing before, but it looks nice.
Hacker Monthly issue #11 is out now, and here's a PDF of my article.
I wrote long ago about the trouble I had with Net::XMPP while setting up a notification hook for Archiveopteryx, but I didn't think anyone would find the script itself particularly interesting. But people have asked me about it, so here it is.
When the Archiveopteryx source code lived in Perforce, we would submit
everything to the
src/main branch, review and test, then
p4 integrate to merge selected changes into release
src/rel/2.0. The only changes we submitted
directly to the latter branches were release-specific, like setting
the version number in
Jamsettings. We could safely re-run
p4 integrate at any time, and it would show us only those
changes that we had not already reviewed.
When we moved to git, we continued to work this way—development happened
master, and we would use
git cherry-pick to
integrate or backport selected changes into older release branches. New
release branches were created by branching from the current master, and
maintained the same way. We did this for almost two years and several
releases, but it was not much fun.
There was no easy way to answer the question
Which commits do
I need to consider for inclusion? for any given release branch. In
git log --cherry-pick will tell you, but it doesn't
work very well. We used to do monthly releases, but it was so painful to
deal with the build-up of commits at release time that we were forced to
backport changes in smaller batches throughout the month (but that was
not, in itself, a bad thing).
I wrote a git
post-commit hook that looks at certain files
in my repository whenever I change them, edits them a bit if it wants
to, and commits any changes it made. The changes it makes are not very
interesting, but such a hook could, for example, be used to maintain
"Last modified: ..." lines in static HTML files as shown below.
Let's say we want to update all
foo/*.html files that
contain something like the following line:
<div class=lastmod>Last modified: ...</div>
The idea is simple: use
git diff --name-only HEAD^ HEAD to
get a list of the files that were changed by the last commit, pick the
ones we're interested in, edit them using sed, and commit any changes