Over and over again, I have the need to synchronize files between my home computer, my office laptop, and possibly other computers as well. I use git because a lot of these files are things that I might conceivably want to keep a history of, and also because git makes it easy to set up a work environment on another computer.

Project metadata files get in the way of this, though. These are the files that fancier editors use to keep track of things like which files you had open, what syntax highlighting schemes you were using, and so on. The file typically gets changed every time you open the editor. Now, most of that information is pretty trivial, and I typically don’t want to synchronize it between computers or keep track of its history. On the other hand, when I’m setting up on a new computer, it’s pretty handy to have a project file available to start with, so I’m reluctant to exclude the files from the archive entirely.

Today, I found a solution. After you clone your git repository, in the new work environment, run

git update-index --assume-unchanged <projectfile>

This sets a flag which …

Since the beginning of version control, people have been using VCSs to manage websites. It works pretty well, because the process of web development is similar to the process of programming. Heck, with the advent of dynamic websites these days, often half of web development is programming. But web developers have one peculiar requirement that most other programmers do not: they have to maintain one particular copy of the site which gets continuously updated, but not always with the latest changes.

Typically, when you set up a version control system to handle your website, it works like this: you have a working copy on your computer, a repository on your server, and another “live” working copy on the web server which is the actual website content. Whenever you want to update the website, you push (or commit) changes from your computer to the repository, and have a hook script set up that makes the VCS update the live working copy with the latest changes. That’s the approach I found described in a couple of websites: http://danielmiessler.com/blog/using-git-to-maintain-your-website and http://toroid.org/ams/git-website-howto.

But once your site turns into a moderately complicated system, this doesn’t …

One of the things everybody points out about git is that it’s a fairly complex system. Of course, other version control systems like Subversion are complex as well, but git doesn’t seem to do as much as the others insulate you (the user) from what’s going on “under the hood.” Case in point: the difference between merging and rebasing.

Merging was a simple enough idea (not) to get used to when I was using Subversion. Basically the idea is this: you have your copy of the versioned material (in Subversion: the working copy), and somewhere else there’s a remote copy of the material (in Subversion: the repository). When both your local copy and the remote copy have been modified since they were last synced up, you have two sets of changes to the same data: your local changes and the remote changes. If you’re going to sync your copy to the remote copy again, you need to combine those two sets of changes. The way Subversion does it for you is a two-step process (which in Subversion terminology is called “updating”):

1. Compute what (remote) changes were made to the remote copy since you last synced …

I’ve been watching git with interest for a while now, because the concept of a distributed version control system — one where you don’t need to contact a central server to make a record of your recent changes — would go pretty well with a lot of the things I use version control for. (Not just source code, but managing homework and papers that I type up in LaTeX) I’ve been stuck on Subversion for a while, mostly because I have a nifty GUI for Subversion for which no worthy equivalent exists for Git, but lately I realize I’ve been using the standard command-line client most of the time. So why not take the opportunity to switch over to git? (Plus, I wanted to get a nifty new toy to play with ;-)

One thing about git which took a couple days to really figure out is the idea of having a repository in every working copy. They say this in all the documentation but somehow I never quite got it until trying it, so I’ll repeat: a git working copy is like an SVN working copy with its own built-in, private repository. In SVN, when you commit …