ExpanDrive

The thing I miss most about Perforce is the absence of good tools for visual diff comparison. With a bit of work, you can get a reasonable approximation of this functionality using Changes.app.

First, install the Terminal Utility using the Changes drop down menu. This installs chdiff, a utility that will let you load up two files for diffing in git.

There are two good options for viewing Git diffs. The first lets you view the diffs in serial order, loading up a series of windows in Changes. To get that running you only need to set the GIT_EXTERNAL_DIFF variable to point to this script:

#!/bin/sh<br/> [ $# -eq 7 ] && /usr/bin/env chdiff –wait “$2″ “$5″

Another option is this ruby script on 5xm.org which will check out two particular revisions to a temporary folder, and then allow you to diff the entire trees in place.

The Changes.app wiki offers some more advice on Git and other SCMs, if you’re in search of more help.

Here is a great post by Mathieu Martin about how to use Git to maintain and extend a long term fork of a project.

Recently at GiraffeSoft we started a new project, based on another existing project we already had going. We could call this a long term fork.

I’m sure you’ve done this before. You were probably using Subversion, and your project is probably 2 years behind HEAD of the original project.

Your invariants probably looked something like this:

• * These projects will both keep being actively developed in the future;
• * They will have some fundamental differences that will not be reconciled;
• * They will however keep many similarities and we expect that they will benefit from the exchange of some specific patches, as development on both moves forward.

This happens all the time, especially in web development. You find a fantastic open source project to base your project on, but you need to customize and extend it. You also want to easily incorporate future features and bug fixes from the original project as they’re developed.

In days past, this problem could have been solved reasonably well by cloning the central repository and then exchanging patches and applying them manually.

I’ve tried this before. Remember that scene in the Dark Knight where the Joker makes the pencil disappear? It’s kinda like that.

As you’ve guessed already, we’ve decided to try using Git to help manage this long term relationship.

It’s still not going to be easy unless you control both projects, but using a setup like Martin describes will be much easier than checking the man page for patch as you try to merge in new features by hand.

Getting started with Git? Git for the lazy is one of the better starting points we’ve seen [via SvN].

There are a million Git cheat-sheets out there, but this one does a pretty good job at picking the more intuitive way of performing a particular task, and showing some sample commands to get it done. The How To Fix Mistakes section is particularly useful, and succint:

Haven't committed yet, but don't want to save the changes? 
You can throw them away:   
git reset --hard   

You can also do it for individual files, but it's a bit different:   
git checkout myfile.txt   

Forgot something in your last commit? That's easy to fix.   
git reset --soft HEAD^   

Then write over the last commit:   
git commit --amend   

Don't make a habit of overwriting/changing history if 
it's a public repo you're working with, though.

If I read another post with a laundry list of why git is useful, each bullet linking me to the man page, I’m going to scream. How much time do you think I have?

There is no shortage programmers coming over from Subversion who feel confused and perplexed by all that Git has to offer. My biggest complaint about Git is that there are quite a number of ways to accomplish a specific task, and it’s not always clear that the best practices are.

I’m sure you’ve heard about Git. Chances are you’re still using subversion. You scratch your head and ask: “Why switch away from subversion, it does everything I need?” Or maybe: “Why on earth would I want a distributed version control system? Screw you fanboy.”

For a long time I felt the same way. All the hype seemed weird; it’s just version control. I felt: “Git, probably pretty neat—but I don’t really care.” Is it going to make my day any better? Probably not. Is it going to be better than perforce, which is ridiculously expensive for a small business? Probably not.

It turns out I was wrong.

When the Rails project migrated away from subversion to Git, I thought I’d give it another look. Our nightly subversion backup had grown to 400+ megabytes, mostly due to an infuriating 7-year old subversion bug/limitation/feature that won’t let you fully obliterate a file from the repository. It sucks to inadvertently check in a 10 megabyte DMG knowing it’ll be in the repository FOREVER.

After the release of ExpanDrive, we were at a point in our development cycle where we had a little room to re-evaluate our development toolchain and see if our current process could be improved. At Jon’s urging, we gave it a shot. Using git-svn [awesome], we imported our entire source tree and history into a hosted GitHub repository. We’ve been using it full time for about a bit over a month are loving it. GitHub does a great job and provides a wonderfully simple interface. It could be better, but that’s another post. In the next few days we’ll be posting a series of articles on the highs and lows of our first month with Git.