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:
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:
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.
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...
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.
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.