I couldn’t find a good article on setting up git-p4, and for some reason most of the articles out there point to dead URLs. So I figured I’d quickly write this up.

Git-p4 is a tool for using git on top of a perforce server. This is great if your team wants to work with a DVCS, but your company requires a centralised VCS.

There were multiple github projects 1, 2, 3, that had forks of the git-p4 script, however, I found the latest mixed in with the official git source code. So download it from here. Tip: Don’t forget to “chmod +x git-p4.py” once it’s downloaded.

Next, I wanted to be able to type “git p4″, so I used an alias to do this. Edit/create the file ~/.gitconfig and add:

[alias]
p4 = !~/bin/git-p4.py

Once that’s done you should be able to:

# Fetch only the head
git p4 clone //depot/path/to/project/ project

# or Fetch all revisions (takes a little longer)
git p4 clone //depot/path/to/project/@all project

If that returns an error, such as “p4 returned an error: Perforce password (P4PASSWD) invalid or unset.”, then you most likely don’t have your p4 command line set up. To set mine up, I added the following to my .bashrc

export P4CLIENT=myclient
export P4HOST=perforce:1666
export P4USER=myuser
export P4EDITOR=nano

and then logged in

p4 login

More information on that set up can be found in the official documentation.

Once cloned, you can change to the project directory and use many of the normal git commands, such as “git log”. You may notice that your newly checked out git repo only has one commit. If you want to see a full history use @all on the end of your depot path.

So I spent the better part of my evening trying to track down a bug, which turns out to be a “feature” of python.

I had just installed the GitPlugin for trac but I started to experience problems. When browsing the source inside trac it was taking over 30seconds to load the page and sometimes it would fail completely. A lot of searching didn’t help much, so I attempted to debug the problem myself. The first thing I noticed was Apache was taking 100% of the processor for a good 30seconds. I attached strace to it and saw something like this:

[pid 22682] close(43029)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43030)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43031)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43032)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43033)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43034)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43035)                = -1 EBADF (Bad file descriptor)
[pid 22682] close(43036)                = -1 EBADF (Bad file descriptor)

This obviously didn’t look good! After some tinkering I found the problem went away when I ran trac standalone, instead of using mod_python or fcgi. This turned out to be a bit of a red herring because I spent my time trying to figure out what was different between a standalone executable and one being run inside Apache.

After playing around with environment variables, I gave up and attempted to printf debug the trac git plugin. I found that the actual call to git was taking on the order of seconds, whereas calling it myself from the command took milliseconds. The line of code (in PyGIT.py) looked a bit like this:

p = Popen(self.__build_git_cmd(git_cmd, *cmd_args), stdin=None, stdout=PIPE,
			                                        stderr=PIPE, close_fds=True)

Now, when I removed the close_fds argument the problems went away! After some more digging I found this bug report which describes the behaviour of close_fds. Python will spin in a tight loop calling close for all possible valid fd number just incase it was previously used. WTF! You can see the python code here:

def _close_fds(self, but):
    os.closerange(3, but)
    os.closerange(but + 1, MAXFD)

So the simple fix to this was to remove the close_fds, so that Python doesn’t stupidly spin calling close(). I suspect the reason I only noticed this when running inside Apache, is because Apache must have a larger MAXFD. Hopefully in the future Python will change this behaviour and find a more sensible way to close all file descriptors, especially when I read this bug report which advises changing close_fds default to true.

Make git colourful

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Make nano colourful

cp /usr/local/share/examples/nano/nanorc.sample ~/.nanorc
# or
zcat /usr/share/doc/nano/examples/nanorc.sample.gz >~/.nanorc

# then
nano ~/.nanorc

To trim trailing whitespace from *.cc on Linux (taken from this blog):

find . -name '*.cc' -exec sed -i {} -e 's/[ \t]*$//' ';'

and on BSDs:

find . -name '*.cc' -exec sed -i '' -e 's/\ *$//' {} ';'

Linux style ‘ls’ colours on FreeBSD (taken from here):

export CLICOLOR="YES"
export LSCOLORS="ExGxFxdxCxDxDxhbadExEx"

To ensure the http_proxy environmental variable is passed to sudo. Edit the sudoers file by running visudo. Then add the following.

Defaults env_keep += "ftp_proxy http_proxy https_proxy"

Bash autocompletion on FreeBSD:

cd  /usr/ports/shells/bash-completion
sudo make install clean

Edit ~/.bashrc and add

if [ -f /usr/local/etc/bash_completion ]; then
    . /usr/local/etc/bash_completion
fi

Make svn output colorful
Edit ~/.subversion/config

[helpers]
diff-cmd = /usr/bin/colordiff

Create diffs with function names and ignoring whitespace

svn diff -x -uwp

To be continued…

Recently I tried TortoiseGit, a TortoiseSVN style Git client, however there were no binaries for my 64 bit windows machine. The 32 bit version found on the official site would install, but the shell extension unfortunately does not work.

So I took the law into my own hands and went and built my own version.

So here is TortoiseGIT 0.3.3.0 (64 bit) built from revision 9d3351f627b26d9555794e785cf8bbae22155f12. There is now a newer offical version available at: http://code.google.com/p/tortoisegit/downloads/list

Hopefully 64bit builds will be available from the official site in the future.

Disclaimer, I haven’t fully tested this app, and I suspect some features of the 64 bit build might be broken. Regardless I’ve been able to use at least the basic features of this version.

Today I presented a CAKES talk in our department to help teach people about version control systems. I hope by sharing my knowledge on a subject, that others will share theirs. Below is the abstract and slides for my tak:

This talk aims to explain what version control systems (VCS) also known as source control management (SCM) are, how they work, and how to use them. This includes explaining why you should use VCS for your every day projects, even if they don’t include any source code. The differences between the main two classes of VCS; centralised and decentralised systems will be discussed, outlining both their benefits and disadvantages. This presentation will give you practical knowledge to start using systems such as subversion (SVN) or git, as well as many example use cases. Bottom line is that using a VCS can help you keep your work organised, backed up, revertible, whilst allowing contributions from multiple users. This talk is for anyone that has heard about CVS/SVN/git but was never quite sure what it was, or how to use it.

Download Slides