Friday 20 June 2008

Git: is not so great for managing patch queues actually

I found myself doing a bit more work on module-init-tools than planned. The good news was that it had a testsuite. The bad news is I had to fix the testsuite first to work on my computer, then to get it to use valgrind as documented.

I also ended up fixing a number of memory leaks. These are unlikely to important in module-init-tools where all the programs are short running commands. However, they make it much more difficult to use valgrind to check for leaks in my new code.

Plus, while I was grokking all this existing code it seemed a pity not to profile it and shave some time off the hotspots (again, using valgrind, also with wonderful profile graphics from kcachegrind).

As a result, I currently have 12 patches with just under 6000 lines. My first approach was to import all the changes into separate commits in Git - hence the GitHub account. This is, it turns out, the Wrong Thing To Do. It's very cumbersome to go back and correct a commit if you miss something, or as a response to feedback.

So I'm now using "guilt". This is much like Andrew Mortons "quilt" patch management system, except it lets you feel superior for using Git underneath and not having to type "quilt add" every time you edit a different file. I've already used it to reorder my patches and regroup them more logically, and it works great.

What I'm trying to say here is that all the history I published on GitHub is now obsolete, and I'm going to blow it away :-). Before I do that, hopefully I can work out what the murmerings about tracking your patches directory in Git mean - then I can publish my patch queue on GitHub.

But now I have to go collect my SDM open assessment feedback. I was hoping to meet with Niall at the same time but he's not replied. Oh, and maybe I should get some food in the house.

No comments: