My thoughts on Git

May 30th, 2009 by sjan

I have been working with Git for a while now, and I have a few thoughts about it. I am used to the SVN model, where multiple developers check out of a central repository, make changes locally and then commit them back to the repo (and repair failed merges). While SVN is not perfect, at least I am comfortable with it and know what to expect from it. While some of my issues with Git may relate solely to my relative unfamiliarity with it, at least it seems like I am not the only one with issues.

In reading through the man pages and all the documentation I can find on line (including the Git – SVN Crash Course) I was totally unprepared for what actually happens. According to the Crash Course git commit -a does the same thing as svn commit, but that is not quite the case. After a commit the files still need to be moved to the repo. So as I am looking for the best way to do that I find git push. Well, it would seem to me that firing off a git push would mean that I want the files I have modified and committed to merge into the repo I checked them out of. But that isn’t quite what happens if there are any working directories checked out the repo (meaning the one you are working on). It seems that the only way to properly get the files back into the repo is to issue a git pull from the repo aimed at your working branch. Hans Fugal said it best in his post from last year: git-push is less than worthless.

What this means is that I am unable to easily move changes from my laptop to the server. Instead, in order to reduce the number of steps I need to take I check out the repo I am working on (git clone) in my home directory on the server and then use sshfs to mount that directory locally. I do my work there, and then ssh in to the working directory, fire off git commit -a and then cd to the repo to pull from the working directory. Of course this seriously hampers my ability to work offline (as in I can’t). While I am sure there are plenty of good things about Git I am not yet really seeing them. With the exception of git stash I have yet to be wowed by anything Git has to offer. In the interest of fairness, however, I have not been incredibly wowed by anything SVN has to offer either, I just find it easier to use.

SVN on OS X – /usr/bin or /usr/local/bin

December 24th, 2008 by sjan

I recently installed the openCollabNet OS X Universal binary for SVN 1.5.4 from Tigris and found something odd. I had installed the openCollabNet binary for 1.4.4 a while back, and don’t recall changing any install paths, but apparently something changed. After installing I ran svn –version and saw something that I shouldn’t have seen:

svn, version 1.4.4 (r25188)
compiled Sep 23 2007, 22:32:34

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see
This product includes software developed by CollabNet (http://www.Collab.Net/).

Strange, I should have seen the new 1.5.4 there. So I did a bit of digging. Everything I saw about the openCollabNet binary said it installed in /usr/local/bin, but when I ran which svn I saw /usr/bin/svn. So I looked in /usr/bin and /usr/local/bin. Sure enough, two installs in two different places. Not being one to do anything rash (like deleting svn from /usr/bin and then changing the path on all my tools that rely on it) I decided the best thing to do was fix it in a way that was reversible. So, I fired off a sudo ls (to get my password in scope in the shell) and then a simple

for i in `ls /usr/bin/svn*`; do mv /usr/bin/$i /usr/bin/$i.old && ln -sf /usr/local/bin/$i /usr/bin/$i; done

Once I had fired off that command another call to svn –version revealed the fix:

svn, version 1.5.4 (r33841)
compiled Oct 27 2008, 11:19:10

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see
This product includes software developed by CollabNet (http://www.Collab.Net/).

I am still a little confused as to how 1.4.4 ended up in /usr/bin while 1.5.4 went to /usr/local/bin (where it is expected to go from the openCollabNet binary installer). I wondered, did I change the install path at some point in the install? Somehow I doubt it, as that is not a change I would be likely to make. Just another little mystery for the unsolved cases file.

WordPress 2.7 SVN headaches

December 19th, 2008 by sjan

When upgrading my blog to WordPress 2.7 using my favorite method (svn sw) I ran into the same problem plenty others were seeing from standard ftp upgrades. Namely: Fatal error: Call to undefined function: wp_remote_request() in /... path to blog .../blog/wp-includes/update.php on line 58. (See more about it here: I tried all sorts of craziness, including deleting everything but my uploads, my images and my custom theme, and then doing an svn up. Still no good. So finally, I got desparate. I did a fresh svn checkout of the 2.7 tag, copied my config, themes, uploads, images and plugins from the old version over, and all was good.

You can imagine, I am sure, that I was not really happy about the thought of going through the whole ordeal again for my wife’s blog. As fate would have it, svn sw worked like a charm on hers. Go figure.