Ramblings

At work, we use Borland Starteam for code management and bug/change tracking. Lately, I have been using Git for code management, in addition. I really like having the benefits of Git, while not forcing the other developers to change how they work. Git can track all my little code changes, and then I checkin to Starteam to share with the other developers

I keep a Git bash (part of mSysGit) shell open all day while I’m working. It took a little while to get used to looking at Unix-style diffs (comparison of the last version of a file and what is currently on the disk), but now I definitely prefer it to working in Starteam or with TortoiseSVN which force you to use the mouse. Also Starteam has the nasty habit of not being able to determine the Status of a file, constantly saying Unknown even after an explicit Refresh (F5) and right click -> Update Status, instead of realizing a file is Current or Modified.

Integration: Starteam, TortoiseSVN vs. commandline

I read a lot of blog posts where people say they don’t like git or other similar DVCSes because they don’t have good visual clients. I find that I am able to get to the information that I want to a lot easier (and it feels faster whether or not it is). I alt-Tab from Delphi to my Git Bash look at what files have changed, maybe look at what changes have been made, commit the change or revert it, and then alt-Tab back to Delphi. Git has never gotten confused about a file status, I have seen TortoiseSVN show the wrong icon, and Starteam routinely gets the status wrong, or caches it, or just plain can’t figure it out. Using git bash, I can stay at the root of the repository and see that a file was changed 5 sub-directories down, exactly which file it is, and optionally see exactly the changes made. Quickly, without taking my fingers off the keyboard. I’m assuming you’re a programmer, if you’re reading this, and I think that you should be comfortable with the keyboard and a command-line (whether it’s Windows’ cmd.exe or the linux-like git bash)

Git is Very Fast

Git is a DVCS (Distributed Version Control System) which means you can work without a server of any kind. Git handles this by storing everything in a “.git” directory at the root of the repository. When I was first trying Subversion, it was annoying to see the “.svn” directories it creates in each and every subdirectory in the repository. And it only stores the history of the last commit, it has to go back to the svn server to get more; git stores the full history. I can see the whole history or any part of the history with ease.

Lately, I’ve also been using git for temporary repositories. Often, I will need to create a SQL script for a release. It usually consists of several parts, and when there are quite a few, it can take a while to find the section I’m actually trying to fix. Now I will create a git repository (all you need to do is git init) and work with each piece of the script as a separate file. When the script is working and ready, it gets put into Starteam and the git repository is deleted, quickly and easily (it’s just a directory of files in .git\).

Git makes copying between repositories easy

Starteam’s sharing model is that it runs a server which clients may connect to in order to retrieve information (change request, task, source code, etc.), since git has no server component, sharing is quite different. Basically, you tell git to pull and push to places that you set up as remotes. A remote is any other git repository. I have a remote which goes to a directory hosted by a local IIS server, so my co-workers can pull my entire history anytime they want. I also have a remote on a 4GB USB drive (though it does not need to be very large, the main repository is only 18MB for the last 8 months of history), which allows me to take my full history home with me, without any security issues like hosting something over the internet (except, of course, if I were to lose the USB drive).

The two remotes I have set up are bare remotes, meaning they never have files checked-out, they only have the history of the repository (so they’re only used for pushing and pulling to). You can setup a new bare repository, for instance to an IIS directory:

cd \Inetpub\wwwroot\git\
mkdir repo.git
cd repo.git
git --bare init
mv hooks/post-update.noexec hooks/post-update # this allows the repository to be pulled correctly over HTTP

then you add the remote to your repository, for instance if your code is at C:\code\

cd \code\
git remote add public \Inetpub\wwwroot\git\repo.git
git push public master

now whenever you want to make all your changes available to others, you just have to git push public

Open source sharing, free and easy with GitHub

There are many options for sharing code with others on the internet. So far, I’ve been creating a zip-file of my code and making it available to download from my website. I think it works fine, unless I find a problem and want to change it. Also, if someone just wants to look at the code, they have to download and unzip the file. I haven’t spent a lot of time with it, but GitHub makes a lot of this easier and better. It is free to sign up and put open source code (you can put closed-source code, accessible only to whom you say so, but the plans cost money); it uses git, so it has the full history of the code, and is very easy to update (if you set it up following a tutorial like this, you just need to git push); and it allows anyone to navigate the directory structure and view text files right from the website.

I have made my code from this blog available in this repository.

I only wish more people using Delphi would use GitHub.