[Users] EinsteinExact/thorns

Barry Wardell barry.wardell at aei.mpg.de
Mon Nov 28 10:51:30 CST 2011


On Mon, Nov 28, 2011 at 3:53 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote:

> I like your setup where EinsteinExact "contains" another repository
> "thorns". I assumes that makes it much simpler to regenerate code
> without needing to handle spurious conflicts.
>

This was the intention, although the jury is out on whether it really is an
improvement. Ian and I decided to try it out as an experiment and have
mixed opinions about whether it was a success. I think it does help to keep
the history cleaner for the main repository and it's nice to always be able
to comfortably throw away any local changes in the thorns repository (for
example, you can do a 'git reset' instead of worrying about rebasing).

The downside is that because of the way git's submodules system works (see
http://book.git-scm.com/5_submodules.html for a good description), it is
still necessary to have a commit on the master branch whenever the thorns
are regenerated. On top of this, now whenever a change is made it has to be
pushed twice, once for the master branch and once for the thorns branch.

Can we copy this for McLachlan? Can you briefly describe how to set
> this up, and how we would have to extend GetComponents (if at all) to
> make this work?


This is certainly possible and very easy to do. It essentially amounts to
 creating a separate repository for the generated thorns and adding this as
a submodule to the main repository. GetComponents then needs to clone the
repository with the --recursive option. Also, when pulling in new changes,
it's important to remember to run 'git submodule update' after pulling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20111128/ec72cccf/attachment.html 


More information about the Users mailing list