GitSuperRepoUsersGuide
Contents
Introduction
We provide a Git super-repository of the Einstein Toolkit. This is a Git repository which contains http://progit.org/book/ch6-6.html for each of the components of the toolkit. Each of these submodules is a pointer to a Git repository. Since some of the components of the ET are maintained in SVN or Mercurial rather than Git, we maintain Git mirrors of these.
This page describes how to check it out and work with the Einstein Toolkit super-repository. It is currently more of a tutorial than a User Guide.
Checking out
git clone --recursive git://git.barrywardell.net/EinsteinToolkit Cactus
This takes about 10 minutes and will create a directory called Cactus containing the entire Einstein Toolkit and all its version history. When it is done, setup the git-module package which provides convenience functionality:
cd Cactus ./bin/git-module setup
This adds a command to add git-module to your PATH in your shell startup file (.bash_profile or .profile). You should run this now to have access to git-module on your PATH:
source ~/.profile
or
source ~/.bash_profile
You will need to configure simfactory as usual either by using "sim setup" or by creating a simfactory/etc/defs.local.ini file by hand.
What's new?
To see the commits that are available on the server, use
git module summary
Commits that you would get by updating are listed in green, and those that you have made locally that you probably want to push are listed in red.
Viewing local modifications
You can see at a glance which of the submodules have local changes using
git status
You can then go into each submodule and see those changes using git status or git diff.
Viewing history
In addition to the super repository being a git repository, each sub-repository is also a separate fully-fledged Git repository, so you can go into each one and type "git status", "git log", etc. This works for repositories which are SVN or Mercurial upstream, because we use git-svn and hg-git to convert the repositories to Git on the server. You can also use the usual graphical tools (we recommend GitX for Mac OS, and git-gui/gitk for Linux) on each subrepository to visualise the log messages and patches, see which files have local changes, and interactively commit parts of files.
Updating
If you want to pull all changes from the server, use
git pull git submodule update
Checking out a specific branch
If you want to use a particular Einstein Toolkit release, perhaps because the current development version is unstable, use
git checkout ET_2011_06 && git module checkout --all
The tree will be very quickly updated to match the release. All changed files will have updated datestamps, so you should be able to trust the Cactus make system to recompile only what is necessary. However, it might be safer to delete any configurations and build them again.
Committing
For sub-repositories which are upstream (as most are), regardless of which revision control system is used upstream you must first initialise the sub-repository for committing:
git module init-upstream <submodule-path>
from the root Cactus (super-repo) directory. You can get a list of the available submodules with "git module ls" or by using tab completion if your shell is bash. Once you have completed this process for a submodule, you can treat the submodule as a regular git repository and commit as normal. The method of pushing depends on the version control system used upstream.
Git
For thorns whose source repositories are in Git already, you can commit and push as normal in the subrepositories.
git push upstream ...
SVN
For submodules which use SVN upstream, you can commit directly to the source SVN repository using, from the submodule directory,
git svn dcommit
assuming you have commit rights in the source SVN repository. This will push any local commits to SVN.
Mercurial
For Mercurial upstream repositories, it is more complicated, as there is no git-hg (equivalent to git-svn). In this case, you make commits locally to your submodule as if it were a regular git repository. Then, when you want to push upstream:
cd <submodule-path>.hg hg pull git # Pull from the git submodule hg push # Push to the upstream hg repo