CVS To Git Transition Page

This page documents several important issues pertaining to Flux's transition from CVS to Git.

Common Tasks

Cloning

The command to clone from the Emulab git repository is

git clone git-public.flux.utah.edu:/flux/git/emulab-devel.git

Updating

If you have no local changes, you can update your copy of the source by doing:

git pull

This is equivalent to cvs update if you have no local changes

Maintaining Local Changes

The best way to maintain local changes is to create a branch:

git checkout -b mybranch

(note: because you have a full copy of the repository, operations such as creating a branch are only local; this won't create a branch in the main repo.)

Once you've made some changes, commit them (again, your are committing to your local repository only, not the central Emulab one):

git commit

To pull in code from the main Emulab repository, do this:

git fetch

This will get you a copy of changes made at Utah, but will not change your checkout out copy or your branch. You can find out what has changed in the Utah source:

git log mybranch..origin/master

... to see commit messages only, or

git log -p mybranch..origin/master

... to also see diffs.

You can merge the latest Utah code into your local branch by doing:

git merge origin/master

Switching to the Final Repository

The transitional repository has been deleted now that final conversion to Git is done. The final repository is different from the transitional one due to different commit hashes. This means you will need to clone the final repository and discard your clone(s) for the transitional one.

Moving Topic Branches

To move topic branches over from the transitional repository to the new one, you can do the following (assuming your old topic branch was based on master):

cd <newrepo_path>
git remote add oldrepo <oldrepo_path>
git fetch oldrepo --no-tags

Then do the following for each topic branch you wish to move:

git branch --no-track <topic> oldrepo/<topic>
git rebase --onto master oldrepo/master <topic>

Note that this will rebase your topic branch onto the head of the new master branch. If this isn't going to work for you, then you'll need to find the commit in the new repository that is equivalent to the one you branched from in the old repository and substitute that commit hash for 'master' in the above command. You can find the branch point with

git merge-base oldrepo/master oldrepo/<topic>

Then use git log on the commit hash returned to examine the log message for the commit, followed by git log master to look for the equivalent commit (i.e. same changes, same message, different hash) in the new repository.

Once you've moved all of your branches, you can clean up all references to the old repository:

git remote rm oldrepo

Optionally, you can tell git to remove all unreachable objects (meaning the objects you added with the fetch command above) and recompress the repository as follows:

git reflog expire --expire=0.minutes <topic>
git gc --aggressive --prune=0.minutes

Checking Out a CVS Sandbox From a Git Server

There may still be some users who need to check out the codebase using CVS. In order to do this, we have set up git-cvsserver which allows CVS access to our main git repository. Use the following commands to check out using a CVS client:

setenv CVS_SERVER "git cvsserver"
cvs -d ":ext:<username>@git-public/flux/git/emulab-devel.git" co <branch>

where <username> is your username on the git server and <branch> is the name of the git branch to check out. For trunk, the git branch is master.

If your CVS client is version 1.12.11 or later, you may use the alternate checkout command

cvs -d ":ext;CVS_SERVER=git cvsserver:<username>@git-public/flux/git/emulab-devel.git" co <branch>

which has the advantage that the CVS_SERVER setting will be stored in your CVS/Root files and so doesn't need to be set in the environment before using cvs.