Let's say that you have a backend build system with BitKeeper dependencies. If you want to do most of your development with Git, while still keeping the BitKeeper backend, here's one way how to do it.
The basic strategy here is to create a new BK repository which will have a git index inside it.
Clone BK repository
$ bk clone /code /home/usr/dkl/repos/code
$ touch /code/mycode/.gitignore
$ bk ignore .gitignore
$ bk ignore 'mycode/.git -prune'
$ bk citool (check in these ignores)
Note in the above I'm restricting the scope of my git index to just /code/mycode. To me, Git seems to be easier to make ad hoc repositories than BitKeeper.
Setup your Git repository
$ cd /code/mycode
$ vi .gitignore
# git doesn't need to track these files with "special meaning" in BitKeeper
# p.* = "pending" (I think)
# s.* = normal tracking file (I think)
SCCS
p.*
s.*
$ git init
$ git add .
$ git commit -m "Initial commit from BitKeeper"
Now you can edit files in git.
One gotcha with this system is if you don't first checkout the files on the BitKeeper side before doing a git fetch/merge/pull.
In other words, you may see an ugly message like this :
check: ``foo.php'' writable but not locked.
This means that a file has been modified without first doing a "bk edit".
bk -R edit -g foo.php
will fix the problem by changing the file to checked out status.
Running "bk -r check -acf" will fix most problems automatically.
You can avoid this problem by first doing a bk edit before you do your git fetch.
To help remind you what you need to checkout, you can do something like this :
$ git diff --stat master FETCH_HEAD
Then do a bk edit on the list of files it spits out.
