ROMS/TOMS Developers

Note: this is a copy of something submitted to the ARSC HPC newsletter.

I’ve written about git here twice before, where I described needing
to deal with legacy svn repositories. Perhaps it’s time to get a
little more specific about how I’m using it so you can all be
suitably horrified.

First of all, I started playing with git before I found a system
with a working git-svn command. I created a repository with a main
trunk which mimics the svn code, plus a branch with exploratory code
we’re not ready to share via svn just yet. I have these codes in a bare
“origin” repository in my home directory on my desktop system. A
bare repository has the database, but no working files – it is
unsafe to push to a non-bare repository.

I can do a “git clone” of the “origin” out to any of the supercomputers
here at ARSC. The “origin” repository doesn’t know about any of the
clones, but each clone can pull updates from the “origin” and push
changes back into it. Good practice means making sure the “origin”
is always up to date with any changes made anywhere.

It turns out the system with the working git-svn is a laptop, though
security prevents the laptop from hosting the “origin”. The laptop
also has a clone of “origin” in addition to the repository generated
by “git svn clone” and a third repository from “git svn clone” on
a colleague’s trunk version. These three repositories know something
about each other. How does that work? Say we create them with:

     git clone  git_code
     git svn clone  svn_code
     git svn clone  trunk_code

We’ll assume that everything is on the master branch below, but it
could be on some other active branch.

Remotes

I can go into git_code and type:

     git remote add svn_code ../svn_code
     git remote add trunk_code ../trunk_code

Likewise, I go into svn_code and type:

     git remote add git_code ../git_code
     git remote add trunk_code ../trunk_code

Because my view of trunk_code is read-only, I have no need for it to
know about the others.

Note that the “git clone” operation automatically generates a remote
called “origin”.

Remote Tracking Branches

I’m not quite set up yet to use the remotes. They need to be turned
into remote tracking branches, branches in the local repository
which point to the remotes. To do this, go into each directory with
remotes and type:

    git remote update

This will create a new tracking branch for each of the remote sites.
These branches show up with “git branch -r” or “git branch -a” but
not with simply “git branch”.

Incorporating Svn Updates

Suppose you decide to check for updates from the main trunk, after a
period of weeks (or years) and you want to bring those changes to
your code. Using svn, an “svn update” would bring a copy of that trunk
directory up to date all in one fell swoop. Ditto with a merge from the
old to the current, even if some dozens of updates have been checked in.

Using git, you invoke the following from the trunk_code directory:

     git svn rebase

This will bring over the changes one at a time, with the svn
check-in message attached to each change.

Now, go to the svn_code directory and type:

    git remote update

Now you can apply the changes via “git cherry-pick”, one change at a
time. Conflicts get resolved as they are encountered, commit by commit.
This could get tedious if you let it go too long…

Once that’s done, it’s time to commit these changes to your svn
repository:

    git svn dcommit

In the git_code directory, repeat the “git remote update” and the
“git cherry-pick” commands, then:

    git commit
    git push origin master

Now your workstation’s “origin” is up to date as well.

Incorporating Git Updates

Sometimes the changes come from you, over on one of the
supercomputers. On that supercomputer, type:

    git push origin master

Now the changes are on the workstation, but not the laptop. On the
laptop in the git_code directory, type:

    git pull origin master

Now go to the svn_code direcotory and:

    git remote update
    git cherry-pick 
    git svn dcommit

This brings your changes over to your svn branch.

Last Thoughts

If I were to start fresh, I would start with the “git svn clone” operation
and create a bare clone of that on the workstation. I could still do
that if I knew how to pull the development branch code from the git_code
to the svn_code repository (any hints from you all?). I’m still enjoying
using git, though it makes me feel like an old dog faced with many
new tricks!

Also, I talked about git at a ROMS meeting and that talk is available
here.