Difference between revisions of "GitSuperRepoUsersGuide"
(→Updating) |
(→Committing) |
||
Line 40: | Line 40: | ||
==Committing== | ==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> | |
− | + | e.g. | |
− | + | git module init-upstream simfactory | |
− | git | ||
− | |||
− | + | 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. | |
− | For | + | ===Git=== |
+ | For thorns whose source repositories are in Git already, you can commit and push as normal in the subrepositories. | ||
− | git | + | git push upstream ... |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | ===SVN=== | ||
You can now commit directly to the source SVN repository using, from the submodule directory, | You can now commit directly to the source SVN repository using, from the submodule directory, | ||
Line 69: | Line 64: | ||
===Mercurial=== | ===Mercurial=== | ||
− | For Mercurial upstream repositories, it is more complicated, as there is no git-hg (equivalent to git-svn): | + | 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 | |
− | cd <submodule-path> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
hg pull git # Pull from the git submodule | hg pull git # Pull from the git submodule | ||
hg push # Push to the upstream hg repo | hg push # Push to the upstream hg repo |
Revision as of 13:49, 27 June 2011
Include here simple user-friendly instructions for using a Cactus super-repository
We provide a Git super-repo of the Einstein Toolkit. This page describes how to check it out and work with it. It is currently more of a tutorial than a User Guide.
Note that these instructions are a work in progress and will not currently work.
Much of this is too complicated to remember and understand. We need to make it much simpler, possibly by providing scripts.
Contents
Checking out
git clone --recursive cactus@git.einsteintoolkit.org: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 && source ~/.profile
Updating
To update the checkout, it is first a good idea to see what would be changed. First enter the top-level super-repo directory. You can get a list of the changes using
git submodule foreach 'git --no-pager log --oneline ..remotes/origin/HEAD'
This assumes that the remote HEAD is the one that is checked out, which is not true for SimFactory, for example. Also, don't we need to do some fetching first?
If this is OK, you can then update using:
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
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>
e.g.
git module init-upstream simfactory
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.
Git
For thorns whose source repositories are in Git already, you can commit and push as normal in the subrepositories.
git push upstream ...
SVN
You can now 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
This obviously has to be improved.
Viewing history
Each sub-repository is 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 upstream, because we use git-svn to convert the repositories to Git on the server. You can also use the usual graphical tools (we recommend GitX from [1] for Mac OS, and XXX for Linux) on each subrepository to visualise the log messages and patches, see which files have local changes, and interactively commit parts of files.
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.