Dave recently wrote about git-svn with multiple branches. Worth a read if you want to use git in a hostile svn environment.

YouTube has a good talk by Linus Torvalds on why you would want to use git.

I think a few points he sold very well, and a few were very Linus-centric. It’s worth a watch.

I released version 2 of my gitdiff.vba vim script.

It now supports two features:

• :GITDiff [commitish]

  Split the vim window vertically, display the HEAD, or some other changeset, version of the file in the split, then diff them.

• :GITChanges [commitish]

  Highlight lines that were changed since the HEAD or some other changeset.

I also started using the VimBall script, which is a package format for vim scripts. So to install it, you need to first have the vimball extension. Further, if you have the GetLatestVimScripts you can use the :GLVS commands to automatically upgrade your packages.

Taking a TODO item off my list, I am adding a plugin to vim that splits the current window and presents a diff between the current file and any revision of that file in the current git repository.

I am giving a intro to git tutorial for oclug tomorrow.

Here are the slides in PDF format. If you are one of the lucky ones and magic point works for you, you can also grab the source tarball.

I got this idea from a blog posting a few months back. I think the guy was using darcs. Unfortunately, I was unable to find the reference to link to him.

Anyway, here is how you can track your /etc directory with git, and have apt update it automatically each time a package is installed.

I wrote about [git caching]{git-caching} several months back. The term, git caching, was something I had given a local repository that can be used as a reference for multiple projects. New features in the recently released git 1.5.x requires that I blog again about this great tool.

Recap: I am working on a linux patch – [klips]{tags/openswan} to be specific. I have more repositories then I know what to do with. Git has this cool feature where it can point to another directory to find it’s object files, this is called alternate or reference repository.

When you clone a new git repository, using a recent git release, by default git will create a .git/remotes/origin with all remote branches. This file lists all remote branches that are to be updated on a fetch.

Over time the remote may get more branches, and it may be necessary to update the remote branch list. The way to find out what is available at a remote is to call git-ls-remote origin, then pick out the branches of interest, and add them to the .git/remotes/origin file.

I try to minimize the amount of data I pull from git repositories. To do this I have a directory on my file server that has a bunch of clones of git (and hg and previously bk) repositories. All of these are exported and mounted on my other machines in /site/scm/. I will refer to this as cache :)

Next, I have a cron job that regularly updates those trees from the their upstream counterparts. All my working copies are cloned from those repositories using the --local --shared mode, or using --reference if I think I will be committing upstream any time soon.

openswan is going through a process of redefining what their versions numbers will mean… what’s stable, what’s testing, what’s devel, etc.

I participated in the discovery of how to do this automagically from git release tags. Patrick was so happy with the results that the conversation ended with …

    14:49 <patlap> C'mon bart, blog it :-)

… and how can I tell the CEO of Xelerance “no” :)