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.