Delphi Programming Observations

Friday, April 3, 2009

Git and Delphi

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.

Delphi and Git Bash

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.

posted by Jason at 11:08 pm  

2 Responses to “Git and Delphi”

  1. Matheus Garcia says:

    > “(…) It took a little while to get used to looking at Unix-style diffs (…)”

    You can configure git to use external tools to view diff output in a more readable format. Look for diffmerge integration at http://therightstuff.de/2009/01/28/Setting-Up-SourceGear-DiffMerge-With-Git.aspx

    In a nutshell, you just have to 1) create a shell script (ou bat) which would receive parameters from git and call the merge tool (eg. diffmerge) from them 2) config git to call that script on merge (just a simple 2 lines config on git config file.

    By the way, at work we still use the poor featured and mouse oriented borland teamsource. Just great when I discovered git and started using it.

  2. Jason says:

    I recently found another way to configure an external diff viewer. Now that I am comfortable with the diff style output, I rarely have a need to see a more graphical and full file difference, and this setup does not change how `git diff` works.

    I think I saw this on stackoverflow.com but I can’t find the exact question right now, and I don’t see a lot of information about it, so it may be a new feature for later versions of mSysGit.

    Basically I added a few lines to my ~/.gitconfig and now `git difftool` will open my graphical full-file diff viewer.
    The lines I added to ~/.gitconfig

    tool = bc3
    [difftool "bc3"]
    cmd = \”C:/Program Files/Beyond Compare 3/BComp.exe\” \”$LOCAL\” \”$REMOTE\” \”$BASE\” \”$MERGED\”
    prompt = false