Until today, this blog ran on vimblog, a hand-rolled minimal script for displaying blog entries. In the last year or so, though, I've become a convert to git, and so what I really want to do is edit my posts on any system, commit them to a git repository, push to a remote and have them end up as blog entries on my server. Fixing vimblog to do this would have been more work than I want to deal with, but thankfully ikiwiki exists, and can do most of what I need.
So, as of now, this blog is in ikiwiki. To get there, I followed (more or less, since I'm documenting after-the-fact) these steps:Posted Sun 17 May 2009 11:16:08 AM EDT
At work we use git, and have an extensive suite of tests for our code, and a set of scripts we use to kick them off manually. Unfortunately, we don't have a nice way to run them automatically.
Here's what I want, described here so I don't forget it. Tomorrow, I'll start looking for something that meets these needs, or can be hacked to do so. Maybe I'll have to implement it all, maybe not.Posted Thu 08 May 2008 04:47:52 PM EDT
etckeeper is a tool, packaged in Debian, that lets you track revisions to /etc in a Git repository. Here's how to install and configure it.Posted Sat 12 Apr 2008 05:32:01 PM EDT
In order to keep things as seamless as possible for the next MIMEDefang upgrade, I've decided that the new modules I'm factoring out will need to live within the MIMEDefang git tree, at least for now. But... I had been working on some of the refactored code in a separate git tree, so now I need to merge it back in. Here's how I did it:Posted Mon 10 Mar 2008 12:04:03 PM EDT
At work, we had been doing MIMEDefang development on master in git, and bugfixes on a branch named 2.63-branch. Over time, master diverged significantly from the current maintenance branch. Recently, we decided to rebase our development work on the maintenance branch, but there were just too many ugly conflicts to resolve. As we didn't want to keep all of the code on that branch anyway, the easiest solution was to rename our 2.63-branch to master and resume development there, cherry-picking some of the useful things from the development branch.
Here's how I did the renaming.Posted Fri 07 Mar 2008 12:45:44 PM EST
Let's say you've got a customer with some code that was pulled from your source repository at some arbitrary point in the past, and now you want to give them a few bugfixes.
So, you just pull out your SCM toolbox, and diff from the release point to now, and send them a patch, right? Waitaminute.... what if you don't have any record of when you gave them a code drop? Uh-oh.
If we were thinking ahead, we would have tagged our tree when we gave them a code drop. But, we didn't. Thankfully, we've moved to git, which lets us find a way out of this mess...Posted Tue 28 Aug 2007 03:04:08 PM EDT
I've recently switched to using git for source control, after svk screwed up a merge on me. Unfortunately, I'm still interacting with a Subversion repository until we convert entirely to git.
One thing that git does really well is merge, so naturally when I need to backport something from our devel tree to our stable release tree, I want to use git. Unfortunately, git-svn doesn't seem to handle branches nicely. Or, maybe it does and I'm just missing something. At any rate, I could check out using git-svn, but pushing the changes back to the branch seemed to break, so I had to hack something. Here's how I got multiple branches working.Posted Fri 08 Jun 2007 11:35:13 AM EDT