Dependency graph

---

The aliraeini/porescale repository

• The following is being prepared to be added to CONTRIBUTING.md file in aliraeini/porescale repository

Working with git submodules

The repository uses git submodule because it allows independent development of the modules, and simultaneously a workflow for integration, version management, testing and collaboration.

It is not as easy as a mono-repo though, the following are some notes for a general development workflow.

---

Using the code as is

# clone all submodules, it will be a shallow clone
git clone --recurse-submodules git@github.com:/aliraeini/porescale.git porescale
cd porescale
make -j 8
make test

Updating a submodule

cd src/SUBMODULE
git fetch --unshallow origin
git checkout main # just to be sure
# make changes
(cd ../../  &&  ls src pkgs  &&  make -j 8  &&  make test -j 2)
# If tests pass, commit your changes and push
git push origin HEAD:main
cd ../.. # back to main shell repo

Testing integration

To push to the main shell repository’s remote (called origin here), make sure all submodules HEAD points to origin/main branch or a commit further up the commit chain, by running:

git submodule update --remote # and pray!

If you forked the main shell repo, instead of building one from scratch, you have to make sure your .gitmodule file is correct; all remotes shall points to the right, potentially forked, submodules.

Then, to build and test locally, run:

clear  &&  make -j 8  &&  make test

Or to run tests on GitHub:

git commit -am "update submudule..."
git push origin HEAD:test

Wait for the tests to pass and push your commit to the main branch:

git push origin HEAD:main

and check that the Github tests all pass.

TODO

• build and package foamxm module separately, it slows down the GitHub builds by ~30 minutes.

---

General notes

• This has a shared git history with ImperialCollegeLondon/porescale upstream GitHub repository

  • The upstream repository will not be merged here.

  • Changes to be merged upstream will be done separately, using an e.g. an upstream fork.

• If you are not pulling/pushing from this repo, create your own detached replica.

• For contributing or keeping up-to-date, create e.g. a fork.

  • In most cases you better fork one or more of the modules, not this repo though.

• You are more than welcome to create a fork of this shell repo, to keep track of latest submodules, which solely undergo bug-fixing maintenance atm.

• You are welcome to submit pull requests, though it should be related to code integration.

• You are welcome to fork and submit pull requests to the submodules too.