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?

Aruabea

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. – Kavanaugh

Answer 1

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.

Kavanaugh

Another advantage to this system is some team members can still keep using ClearCase if they want. It is a bit more fiddly while that's happening, as the git users will need to keep things in sync when a non-git user checks in. Eventually the hold-outs will see the advantages the git users have though, and this problem will disappear! – Kavanaugh

Also, our push-back-to-ClearCase script generated a comment for ClearCase from the git log of changes since origin/master, which it used with "cleartool co -c" and so on, so our cleartool commit didn't need a comment at all! – Kavanaugh

Interesting technique, +1. As the "ClearCase guy" in my shop, I could use the holidays;) But I am also the SVN guy. And Git Guy. And a bit Perforce and CM Synergy guy... No vacations for me, then. – Quartana

Part of it was accidental, because (PLEASE don't ask) we all worked in a shared CC static view. Ugh! Initially, our git solution was just a way of managing our own private working directories, but as a whole it worked pretty well because the shared directory gave us a natural place for our "master" git repo, and also a single central place to make sure git was in sync with CC. – Kavanaugh

Thanks for the great level of detail and the link to the blog article. – Aruabea

Every now and then I look back at this answer and get chills. I've spent a lot of energy working around sad stuff instead of looking for a better job. – Kavanaugh

Answer 2

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.

Maes

I will look into in. +1 for even trying ;) – Quartana

I third that! +1 towards development of git-cc :) – Kavanaugh

We have a new-ish ClearCase repository, and as CCRC 7.1.x is uselessly buggy I gave up today and tried your Python importer. Woah. History imported painlessly, and seems to track main cleanly; and it's fast! Thanks! – Joktan

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.

Quartana

@neves: not directly, in that you need a script to query the git repo, asking for any renamed files (Git will be able to detect renamed files), checkout the source directory in ClearCase, checkout the destination directory (if different from the source directory), perform a 'cleartool move src/file dst/renamedFile', checkin src and dst directory. – Quartana