UPDATE: The change that will break history compatibility will be made on Tuesday Sep. 11th.
There is a known issue with the current public repository that will require us to break history compatibility. We are currently planning on making this change on Monday Sep. 10th. If you have any work based off of the current public repository you should back it up before the 10th.

Trilinos Read-only Public Repository

In addition to downloading release distribution tarballs, users and collaborators have the option to access a git repository containing the source code for Trilinos. Most users will prefer the stability of an official release tarball. The public repository should be useful for those wanting bleeding edge features, and those who are contributing source code or submitting bugs. This repository is updated frequently. Note that the state of the master branch is a development version of Trilinos, and is generally less stable than a release tarball.

The Trilinos Team intends to make a publicly accessible version of the Trilinos repository available indefinitely. However, we anticipate that we will have to on very rare occasion break history compatibility. If we have to break history compatibility, we will announce when we do so, and will provide instructions detailing how users can handle the situation.

The repository can be cloned using the following command:

git clone https://software.sandia.gov/trilinos/repositories/publicTrilinos

TIP: The arguments passed to CMake when building from the Trilinos public repository must include

Frequently Asked Questions

Question: Why does the configuration step fail almost immediately from a clone of the public repository using a set of CMake arguments that works with a recent release tarball?
Answer: This is most likely due to the fact that when building from the development branch in the public repository, it is necessary to include -DTrilinos_ASSERT_MISSING_PACKAGES=OFF in the list of arguments to CMake. This option is set by default for release branches and tarballs.

Question: I would like to contribute to the Trilinos project, but the public repository is read-only. How can I submit my changes?
Answer: If you don't have another arrangement with a Trilinos developer, we ask that contributions to Trilinos be submitted to the trilinos-bugs mail list using git format-patch.
Creating a patch is very easy. After committing all your changes, simply type:

git format-patch origin

A set of files in the format ####-commit_summary.patch will be created, where #### denotes the order in which the patches should be applied.

Question: How can I avoid problems with my repository history after submitting a patch?
Answer: After submitting an accepted patch, we recommend that you update using

git pull --rebase

This will combine the commit that was submitted in patch format with the commit applied to the main repository based on the patch into a single commit. If your repository has duplicate, identical commits after a standard

git pull

you can combine the commits using

git rebase origin/master

Question: How can I increase the chances that my patch will be accepted?
Answer: Before submitting a patch, there are a couple of things that can be done to greatly increase the chances that your patch will be applied to the main Trilinos repository:
  1. Build Trilinos with the options:


    After building, run ctest. This will build and test all Trilinos packages that depend on the packages that have been explicitly enabled, allowing you to exercise the Trilinos test suite for all packages that your patch could impact. Running the test suite on multiple platforms is also recommended.
  2. Write one or more tests, or modify existing tests to exercise the new feature, or insure that the defect addressed with the patch does not resurface.