Difference between revisions of "GitSuperRepoUsersGuide"

From Einstein Toolkit Documentation
Jump to: navigation, search
 
Line 1: Line 1:
 
''Include here simple user-friendly instructions for using a Cactus super-repository''
 
''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.
 +
 +
<span style="color:red">Note that these instructions are a work in progress and will not currently work.</span>
 +
 +
<span style="color:red">Much of this is too complicated to remember and understand.  We need to make it much simpler, possibly by providing scripts.</span>
 +
 +
==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.
 +
 +
==Updating==
 +
 +
To update the checkout, it is first a good idea to see what would be changed.  You can get a list of the changes by
 +
 +
...
 +
 +
If this is OK, you can then update using:
 +
 +
  cd Cactus
 +
  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==
 +
 +
===Git===
 +
 +
For thorns whose source repositories are in Git already, you can commit and push as normal in the subrepositories.  If they have been cloned from a public URL, as for the Einstein Toolkit URL above, you can use
 +
 +
  cd <submodule-path>
 +
  git remote add upstream <new-url>
 +
  git push upstream ...
 +
 +
===SVN===
 +
 +
For subrepositories which are SVN upstream (for example simfactory), you must first initialise the subrepository for committing:
 +
 +
  cd simfactory
 +
  git checkout trunk
 +
  git svn init -s --prefix=origin/ svn://...
 +
 +
You can now commit directly to the source SVN repository using
 +
 +
  git svn dcommit ...
 +
 +
assuming you have commit rights in the source SVN repository.
 +
 +
===Mercurial===
 +
 +
For Mercurial upstream repositories, it is more complicated, as there is no git-hg (equivalent to git-svn):
 +
 +
  hg clone <hg-url> <submodule-path>-upstream
 +
  cd <submodule-path>-upstream
 +
  vi .hg/hgrc # Add:
 +
              # [git]
 +
              # intree = 1
 +
              # [path]
 +
              # git = ../<submodule-path>
 +
  hg bookmark master -r default
 +
  hg gexport # Can take quite a long time (~1 hour for carpet-hg)
 +
  hg pull git # Pull from the git submodule
 +
  hg push # Push to the upstream hg repo
 +
 +
<span style="color:red">This obviously has to be improved.</span>
 +
 +
==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 [http://brotherbard.com/blog/2010/03/experimental-gitx-fork/] 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 uncommitted changes using
 +
 +
  git submodule status
 +
 +
<span style="color:red">Is this right?.</span>
 +
 +
You can then go into each submodule and see those changes using git status or git diff.

Revision as of 04:55, 24 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.

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.

Updating

To update the checkout, it is first a good idea to see what would be changed. You can get a list of the changes by

...

If this is OK, you can then update using:

 cd Cactus
 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

Git

For thorns whose source repositories are in Git already, you can commit and push as normal in the subrepositories. If they have been cloned from a public URL, as for the Einstein Toolkit URL above, you can use

 cd <submodule-path>
 git remote add upstream <new-url>
 git push upstream ...

SVN

For subrepositories which are SVN upstream (for example simfactory), you must first initialise the subrepository for committing:

 cd simfactory
 git checkout trunk
 git svn init -s --prefix=origin/ svn://...

You can now commit directly to the source SVN repository using

 git svn dcommit ...

assuming you have commit rights in the source SVN repository.

Mercurial

For Mercurial upstream repositories, it is more complicated, as there is no git-hg (equivalent to git-svn):

 hg clone <hg-url> <submodule-path>-upstream
 cd <submodule-path>-upstream
 vi .hg/hgrc # Add: 
             # [git]
             # intree = 1
             # [path]
             # git = ../<submodule-path>
 hg bookmark master -r default
 hg gexport # Can take quite a long time (~1 hour for carpet-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 uncommitted changes using

 git submodule status

Is this right?.

You can then go into each submodule and see those changes using git status or git diff.