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?

Answer 1

While it may not be without a few warts (you have been warned), I feel I should mention I have written a bridge of sorts.

http://github.com/charleso/git-cc

Bridging between the two systems isn't easy, and I wish my solution was as half as good as git-svn. A big limitation is that you're really confined to mirroring a single stream; git-cc can't clone all your Clearcase branches (as nice as that would be). However, given that most of the alternative scripts resolve around a single Clearcase view you are no worse off (IMO).

Personally I find history quite important and what other solutions lack is their importing of history into Git. Being able to run git-blame on files and see their real authors is quite useful from time-to-time.

If nothing else git-cc can handle the aforementioned 'git log --name-status' step in Matt's solution above.

I'm certainly curious to hear what VonC and Matt (and others) think of this, as I agree that any bridge to Clearcase is fraught with difficulties and may be more trouble than it's worth.

Answer 2

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.

Answer 3

The one process I usually follow is:

• snapshot cd within a ClearCase view/vobs/myComponent
• git init .

That allows me to consider a ClearCase component as a Git repo.
I can then do all the branching and "private" commits I want within that repo, making the file writable as I need them (possible within a snapshot view).

Once I have a stable final commit, I update my snapshot view, which list all the "hijacked" file: I checkout them and check-in them back to ClearCase.

Considering the Git limits, a repo per ClearCase (UCM) component is the right size for a Git repo.
See also What are the basic clearcase concepts every developer should know? for a comparison between ClearCase and Git.

The idea remains:

• no git-cc
• no need to import all the history of ClearCase (which has no notion of repository baseline, unlike the SVN revisions)
• creation of a Git repo within a ClearCase view for intermediate commits
• final Git commit mirrored in the ClearCase view through a checkin of all modified files.