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.

As you’re no doubt aware, a lot of talented, high profile programmers have announced that they’re moving to git for version control. Many of these programmers (for example, yours truly) have promised to post their impressions, their tips and tricks, their how-tos, and their workflows and the internet for the betterment of humanity.

You may have wondered why so few people have followed through with this promise. I’ll tell you: it’s because we still have no clue what we’re doing. We still pour over the cheat sheet and man pages every time we need to do something even remotely outside of our standard workflow (pull, commit -a, push). And when I say “we”, I don’t just mean those of us at Magnetk. Git is fundamentally different than subversion. It’s taking us some time to wrap our heads around it, and we’re all a little gun shy.

Well, not me. I’m not afraid of making mistakes and looking like an idiot.

Say you add git add a file or directory, and then, before you commit, decide “No, no. I did not want to add that file. I’ve changed my mind. Please do not add that file to the repository. I do not even what my coworkers to know that I thought about adding that file to the repository.” What do you do? git reset -- RegretableAdd.tex. The file will still be on disk, but it won’t get added to the repository when you commit.

If you delete or modify a file, and then decide that you want to get it back the way it was in the last commit, you can just do a git checkout fileToBeRestored.sty, and you’ll get it back. But what happens if you git rm it instead?

$ git rm DO_NOT_DELETE
$ # "I did not mean to do that. That was a mistake"
$ git checkout DO_NOT_DELETE
error: pathspec 'DO_NOT_DELETE' did not match any file(s) known to git.
Did you forget to 'git add'?

Probably not what you were hoping for, right? Can you get back DO_NOT_DELETE? In git, you bet you can.

$ git rm DO_NOT_DELETE
$ # "I did not mean to do that. That was a mistake"
$ git reset -- DO_NOT_DELETE
todo.rtf: needs update
$ git checkout DO_NOT_DELETE

And that’s all there is to it. More to come. The git-reset man page, unlike some of the other git man pages, is extremely readable. It contains sample workflows for such situations as “Undo a commit and redo”, “Undo a commit, making it a topic branch”, or “Undo a merge or pull”.

Corrections and additions are welcome.