I previously wrote on [splitting patches with git]{20081112150409}. This is very similar but deals with removing a file from a commit.

Here is a really cool workflow using git…

Say you have several commits (you can think of them as patches for this exercise) in your current repository and want to split one into multiple parts. There could be various reaons like upstream request, only want to release part of it, remove debug code, etc.

Anyway, there is one commit in your unpublished history that needs to be split.

I must say that I am no fan of [SVN]{tag/svn}, but SVN and I get a long a lot better since I started using git-svn. Long ago a good friend of mine, Dave O’Neill, taught me how to handle multiple branches using git-svn. I had used that technique until Dave taught me how to do it better.

Recently I saw this blog post which referenced Dave’s article talking about the first method. I guess Dave never got around to updating his blog with the better way. So I am going to do that here:

MadCoder wrote today about git-rebase –interactive which is a new feature in git that allows you to easily reorder, or fix patches already applied to the current branch by editing a file… very neat.

My employer (or client, since I am a contractor there) uses [svn]{tag/svn}. I prefer to use [git]{tag/git}.

This following git allows me to update all tracked svn branches in my git-svn repository:

    git config --get alias.svnup
    !git-config --get-regexp 'svn-remote.*url' | cut -d . -f 2 | xargs -n1 git-svn fetch

The way to invoke it is to run:

    git svnup
    git-svn rebase some-remote-snv-branch

You need to put that into your ~/.gitconfig like so:

Some things are easier in [git]{tag/git}. For example to nuke all changes and only keep files that are tracked by git I would run:

    git-clean -d -x
    git-checkout -f

In [svn]{tag/svn} it’s a bit more involved, but not impossible:

    svn status --no-ignore | awk '{print $2}' | xargs rm -rf
    svn revert -R .
    svn update

For extra fun… the svn revert -R will actually stop on any symlinks to directories. Fun!

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” :)