How to bridge git to ClearCase?

Question

I've recently used git svn and enjoyed it very much. Now I'm starting a new project at a different customer. At that site the SCM of choice is ClearCase. I haven't found a baked equivalent of git svn for ClearCase. Is there anybody who has tried to use git locally as a front-end to ClearCase using some tricks, configuration or scripting with any measure of success? If so can you please explain the method used?

IMHO using a bridge makes things worse. ClearCase can serve as a dumb filesystem that you can use full, native git on top of - see my answer below for details of the method we used. — Matt Curtis

Matt Curtis Matt Curtis · Accepted Answer · 2010-02-26T22:33:21

Here's a method that avoids hijacks, which our team used this method quite successfully for over a year, until we retired ClearCase for Subversion (per company policy, although it is a backwards step for our team - we were basically just using ClearCase as a dumb file system, and virtually working natively in git, but now we're using the git-svn bridge which isn't as nice as native git.)

We used two directories, one for the ClearCase snapshot and master git repo, which we shared among the whole team and never edited files in, and one for our "working" directory.

The preparation in the ClearCase snapshot view is:

% git init
% git add **/*.cxx **/*.h **/Makefile (and so on)
% git commit -m "initial"

Then clone in your working directory:

% mkdir ~/work
% git clone /path/to/repo

Work in the working directory, on a branch:

% git checkout -b feature
% ...edit/compile...
% git add -u
% git commit

Make sure the ClearCase snapshot is up-to-date with pristine (which it always was for us, because we shared it among the team, and we all used git).

Then merge the branch onto the master by rebasing it, to avoid an automatic merge commit:

% git checkout master
% git pull
% git checkout feature
% git rebase master
% git checkout master
% git merge feature
% git branch -d feature

% git diff --name-status origin/master

Prepare the ClearCase view by checking out/mkelem/rmname any changed/new/removed files, based off the output of git diff --name-status. We used a hand-rolled script to do this. Don't forget to check out any directories that have added/removed files:

Then push the git stuff back, and check in with ClearCase:

% git push
% cd /path/to/repo
% git reset --hard
% cleartool ci `cleartool lsco -r -short -me`

It seems like a lot of commands, but this includes setup, and your daily workflow doesn't use many commands. You can trivially build a script around the push-back-to-ClearCase step, and discover/show your team all the cool extra git stuff gradually as everyone gets used to the basic workflow.

The real beauty of this system is, after a while when everyone's competent with git, you can trivially ditch ClearCase and all the associated individual monkey work and fees. Maybe give the company's ClearCase guy a much needed holiday and some retraining with the savings. (Sadly at my company the git stuff was all skunkworks, and we've moved to Subversion - forwards from ClearCase but backwards from git!)

I strongly recommend you use the pristine script from ClearCase Globally, Git Locally, which runs in the ClearCase snapshot view and ensures it and git are in sync. We set this up as a cron job that ran twice daily, and also ran it manually whenever we were about to push back to git. Unfortunately the link to the blog post is no longer valid. However the script is still available on Github.

How to bridge git to ClearCase?

3 Answers