The folks at GitHub recently launched Gist which may well be the best code sharing/pasting tool ever. It has nice syntax highlighting and a plain user interface plus you can share more than one file in the same paste or gist. In addition to this you have the ability to create a ‘private’ gist. The quotes are because they are private only by obscurity not by any authentication logic. A SHA1 (I think) key is created and they use that as the url to you new, small git repository but they don’t show up in the view of all gists and a SHA1 is pretty unlikely to have it’s value guessed correctly.

Gist by itself is great news and a useful tool but the thing I find really appealing is that I can use it to keep simple text files in sync across multiple computers. This is incredibly useful to me because I typically track my work hours in a simple text file because our timesheet application is pretty horrendous to use and I want to deal with it as few times a week as possible. So I created a new private gist and added this time tracking text file and now I don’t have to worry about having my hours at work but not at home or vice versa because I can just pull from the private gist. Not only that but now my time tracking sheet is versioned so I don’t have worry about losing notes I make about how I spent my time in the unlikely event someone asks I can find it.

This was a grand breakthrough for me and I was quite pleased. Lately though I got to looking at some task tracking software and found some great ones but I am reluctant to pay for software I know I’m likely to stop using after a little while. Of the free options I didn’t find any which would allow me to easily sync my todo list from my home computer to my work computer. About this time I remembered a shell script I had used about a year ago which tracked all the information in simple text files. After a little looking I found Todo.txt – Task tracking for command line lovers. I dug around for the script on my computer and tried to update it but whenever I listed out my tasks I had this -e being printed in front of the first one. I’m fairly certain it was a misplaced sed argument but with all the regular expressions in the shell script I didn’t want to break things worse. I tried to search for the problem and came up empty on the mailing list but did find a link to a todo manager called Task which even provided an installer for Leopard!

Once I installed the package it was a simple matter of updating the configuration to write files to the directory where my time tracking gist was already located and TADA! easy syncing of time and tasks across multiple computers using the magic of the command line.

I was hunting around looking for information about port from svn to git and getting git-svn to compile on OS X a little while back when I ran across Maddox’s explanation of branch name in command line. At the time I thought ‘Awesome!’ but I was on a mission so into del.icio.us it went to await later discover.

A couple of days ago I found the post again in my bookmarks and proceeded to spruce up my command line with the knowledge in Maddox’s post and in MacTip’s Customize Prompt on OS X article. The long and short of it is that the colors in my command prompt bother me so I cut them out of Maddox’s function and ended up with the following to lead off my ~/.bash_login.

Prompt Setup

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^]/d' -e 's/ (.*)/[\1]/'
}

function gitPrompt {
PS1="\h:\W\$(parse_git_branch) \u\$ "
PS2='> '
PS4='+ '
}
gitPrompt

I have to say I’m quite please with the new addition to my command line!

My place of employment is currently and in the foreseeable future married to SVN repositories which is not a problem so much as an inconvenience at times. I’ve recently been working with Git quite regularly and I have really come to appreciate the benefits of Git’s branching and merging. Then even more recently (in the last couple weeks) I’ve been working with a repository which by necessity has multiple branches (more akin to Git forks) all being developed simultaneously and divergently but which had to be brought back in line with each other with some regularity. This responsibility of managing and merging divergent branches (forks) fell to me and so I spent quite some time wrestling with SVN merges and diffs and patches before feeling confident things were back in line.

Having dealt with this nightmare once I decided I didn’t want to do it again if I didn’t have to and so I started to look at git-svn. Once I had git-svn working on Tiger (which was a feat all on it’s own) I just set out to get the trunk cloned which proved to be a simple matter of running git-svn clone http://example.org/path/to/svn working-directory and waiting for the process to finish. By default though this does not create branches and tags based on the svn standard structure:

root
  |-- trunk
  |-- branches
  |-- tags

I decided to investigate further because it seemed like this should be possible. As luck would have it the first thing I looked at was the man page for git-svn (which was also a pain to create as part of the compile process) which says “git-svn is especially useful when it comes to tracking repositories not organized in the way Subversion developers recommend (trunk, branches, tags directories).” which led me to believe it should be easy to track repositories which are organized the way Subversion developers recommend.

As it turns out it is pretty simple if you give git-svn the URL to the svn root and use some options to tell it where to find trunk, tags and branches it creates them all for you. With those flags the command becomes git-svn clone http://example.org/path/to/svn -T trunk -t tags -b branches working-directory. Now to switch between SVN branches you can use git reset --hard remotes/branchName or create git branches from the SVN branches by typing git checkout -b gitBranchName remotes/svnBranchName. In either case once your HEAD is set to a descendent of a branch created by git-svn executing git-svn dcommit sends the commits you have made in git to the SVN repository using the appropriate SVN location as determined (presumably) by the ancestry of your current HEAD.

For example I created a branch for trunk using git checkout -b trunk remotes/trunk and then made a change to a file and committed it to git’s index. Then I create a branch for an SVN branch, git checkout -b testBranch remotes/svnBranchName, edit some files and then commit to git’s index. Once I decide I’m ready to commit my changes to SVN I use git-svn dcommit and everything is sent to SVN.

I now have all the power of git’s branching and merging in my SVN repository.

For information about migrating author information from an SVN repository to a new Git repository I recommend looking at GitHub’s guide to importing from Subversion.