Some months ago, someone posted a link to my article on using Git to manage a web site to the Hacker News web site, where it was briefly quite popular.
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
use p4 integrate to merge selected changes into release
branches like 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
in 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
theory, 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
we make.