<div dir="ltr">Hi Ian,<div><br></div><div>Wow! This sounds like it will take a bit to adjust to the supermodule way of life, but it sounds very useful. I appreciate your comments and explanations.</div><div><br></div><div>Comer</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 4:49 AM, Ian Hinder <span dir="ltr"><<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><div>On 3 Jun 2015, at 22:04, Comer Duncan <<a href="mailto:comer.duncan@gmail.com" target="_blank">comer.duncan@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi Erik,<div><br></div><div>Thanks for the perspective. Today after getting my macports back in shape, I have downloaded a new(?) the development ET and have built an executable including CT_MultiLevel. I've also run a couple of tests and all seems to be ok now.</div><div><br></div><div>Concerning the development version, when will it be possible to do git pull to get the latest dev version? I use and contribute to one or two other software projects that use github and would hope since ET has or is moving to git that the usual methods of cloning various branches would be standardly available. So, what can you say about when this will be possible from <a href="http://bitbucket.org/" target="_blank">bitbucket.org</a>?</div></div></blockquote><div><br></div></span><div>Hi Comer,</div><div><br></div><div>As Erik mentioned, the ET is not stored in a single repository, because it is a modular system made up of components from many different sources. For example, people need to be able to use Cactus without using the ET. If we make a single monolithic ET repository, and put Cactus into it, then any changes to Cactus in the ET repository would not automatically go back into the Cactus repository. Further, the ET contains some subversion repositories for historical and technical reasons, which is another barrier to having a single-git-repository solution.</div><div><br></div><div>The "official" way to check out the ET is the GetComponents tool. Being able to switch branches within a single tree could be implemented in that tool, though I suspect it would need to be done carefully, as there are several things to consider (local changes, local commits, one repository being on a different branch than another, etc).</div><div><br></div><div>One way to handle a framework containing multiple independently-developed modules with git is to use a repository which contains only pointers to other repositories, known as "submodules". This is often used in other open-source repositories to include required libraries with the code. It is also used heavily by Android developers. Barry Wardell and I have set up such a system for the ET. Unfortunately, it is not a completely smooth solution, as submodules have a reputation for being tricky to work with. As long as you only want to do simple things, you just need a few commands, and things will work fairly well. But the system gives you a lot of power that you can use to shoot yourself in the foot! We work around the subversion issue by maintaining git mirrors of the subversion repositories.</div><div><br></div><div>To check out the ET master branch and all its submodules:</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git clone --recursive <a href="https://bitbucket.org/einsteintoolkit/einsteintoolkit.git" target="_blank">https://bitbucket.org/einsteintoolkit/einsteintoolkit.git</a> Cactus</div><div><br></div><div>If you later need to update to the latest version,</div><div><br></div><div><span style="white-space:pre-wrap"> </span>cd Cactus</div><div><span style="white-space:pre-wrap"> </span>git pull</div><div><span style="white-space:pre-wrap"> </span>git submodule update</div><div><br></div><div>To check out a release branch, you can use</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git checkout ET_2015_05</div><div><span style="white-space:pre-wrap"> </span>git submodule update</div><div><br></div><div>To go back to master,</div></div><div><br></div><div><div><span style="white-space:pre-wrap"> </span>git checkout master</div><div><span style="white-space:pre-wrap"> </span>git submodule update</div></div><div><br></div><div><br></div><div>That covers most of the common operations that you will need to do if you are just using the code, rather than developing it.</div><div><br></div><div>Any modifications to files that you may have made will be preserved on switching branches, unless there is a conflict with a change between the branches, in which case you will get a conflict warning when running git submodule update.</div><div><br></div><div>The top-level einsteintoolkit repository is known as a super-repository, since it contains pointers to other repositories, which have been checked out under the super-repository in your working copy. So operations on the super-repository like those above should be carried out in, for example, the top-level Cactus directory, not within a submodule directory, or they will refer to the submodule repository instead. A specific commit in the super-repository contains pointers to specific commits in the submodules. You can see the history of the super-repository with</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git log</div><div><br></div><div>The different commits shown there represent historical states of the super-repository; snapshots in time of the submodules. You can check out an old version:</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git checkout 468de39937fbb970a3077b97b6c969189255a363</div><div><span style="white-space:pre-wrap"> </span>git submodule update</div><div><br></div><div>The "git submodule update" is necessary because the checkout doesn't alter the checked-out versions in the submodules. You need to do that explicitly.</div><div><br></div><div>The BitBucket super-repository is updated automatically whenever the component repositories are pushed to, but there may be a delay of a few minutes, as it takes a while to scan for all changes, and the server we run this process on is quite old. </div><div><br></div><div>One reason I like this system is that it makes it very easy to go back to a previous state. I am no longer afraid of updating to the latest version of the ET, because I know I can always easily go back to what I had before. I can also easily see which submodules have local changes in their working copies,</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git status</div><div><br></div><div>and what those changes are,</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git submodule foreach git diff</div><div><br></div><div>I can see when I have local commits to the submodules which are not in my copy of the super-repository, or vice-versa,</div><div><br></div><div><span style="white-space:pre-wrap"> </span>git submodule -q summary</div><div><br></div><div>Each submodule (you can get a list with git submodule status) is its own repository, so if you cd into it, you can do all the normal git things. [One annoying feature is that the submodules are checked out into "detached head" state, rather than being on a particular branch. If you do want to commit changes in a submodule, you probably want to create your own branch in the submodule first with "git checkout -b mychanges".]</div><div><br></div><div>The most powerful feature of all, I think, is that I can identify a complete revision of the code by a single git hash, though this feature is not yet so useful, because you also have to make sure that you store a copy of the super-repository that the hash was made in, and all the submodules with the corresponding commits. </div><div><br></div><div>Feel free to use this super-repository if you like; we have been using it for several years, and keep it up-to-date.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div>-- </div><div>Ian Hinder</div><div><a href="http://members.aei.mpg.de/ianhin" target="_blank">http://members.aei.mpg.de/ianhin</a></div></div></div></div></div>
</div>
<br></font></span></div></blockquote></div><br></div>