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.