iPhone Calendar Colors + sqlite

I have a jailbroken iphone and I use google calendar and google sync to take it mobile. The iphone doesn't have a GUI to select the calendar color. If you happen to be using MobileMe then you don't have a problem but if you're using ActiveSync then you have to resort to using sqlite from the command line. You can find instructions here: http://chriscarey.com/wordpress/?p=353

For my own reference here are the sanitized sqlite update commands:
update Calendar set color_r=15, color_g=77, color_b=140 where title = "Blue";
update Calendar set color_r=76, color_g=176, color_b=82 where title = "Green";
update Calendar set color_r=229, color_g=98, color_b=0 where title = "Orange";
update Calendar set color_r=242, color_g=166, color_b=64 where title = "Light Orange";
update Calendar set color_r=212, color_g=95, color_b=134 where title = "Pink";
update Calendar set color_r=181, color_g=0, color_b=13 where title = "Red";
update Calendar set color_r=153, color_g=68, color_b=153 where title = "Purple";

Git With Svn - Update

During the course of working with git-svn we've discovered a slight kink in our previous workflow. We've been using git-wtf to stay on top of the relationships between our feature and integration branches and that's alerted us to the following problem.

Broken workflow:
1. git checkout -b feature
2. Hack, hack, hack.
3. git checkout master
4. git svn rebase
5. git checkout feature
6. git merge master
7. git checkout master
8. git merge --squash feature
9. git svn dcommit

Simply put, that workflow is meant to merge changes from upstream svn into master and then into our feature branch. Then we merge our feature into master (squashed into a single commit) and push that commit up to svn. The problem comes when examining the relationship between the feature branch and master branch at this point. Running a diff between the two branches show that they hold the exact same content and yet git will insist that they are not the same. The solution here is to use the following workflow:

1. git checkout -b feature
2. Hack, hack, hack.
3. git checkout master
4. git svn rebase
5. git checkout feature
6. git merge master (You can also use rebase here depending on personal preference.)
7. git checkout master
8. git merge --squash feature
9. git svn dcommit
10. git checkout feature
11. git rebase master

The additional rebase from master onto feature at the end will first merge all the changes from master and then try to replay the commits on top of feature back. This will fail and git will attempt a 3 way merge only to realize that the content is already the same. In the end, the branches will now have exactly the same commits (unless you had additional commits on feature you didn't merge) and git/git wtf will now tell you that the feature has been merged in.

The other alternative would be to always use rebase at step 6 and commit each individual commit on your feature branch to master and then to svn; that part is up to you and your team.