DuMu<sup>x</sup> and DUNE are community projects and we are happy about all forms of external contributions.
here are many easy things that you can do, like
* read the documentation and tell us where and how it should be improved,
* try to install DuMu<sup>x</sup> on your platform and report bugs if it doesn’t work,
* fix bugs and open merge requests or send us patches
If you decide to contribute code please read this contribution guide.
## Style guide
When contributing code to DuMu<sup>x</sup> please follow the [styleguide](doc/styleguide.md).
When contributing code to DuMu<sup>x</sup> please follow the [styleguide](doc/styleguide.md). Your work will enjoy much smoother sailing if stick to it with your changes. DuMu<sup>x</sup> is a pretty large project, and a consistent way of doing things really helps a lot when trying to find your way around the code.
## Contributing
You should get your changes to us in the following way:
* Get an account for our GitLab instance (you might need to contact us if you can't create projects at first login)
* Fork the core module that you want to contribute to, just as you would do on GitHub
* Push your changes to your fork on some branch
* Open a merge request using the branch you pushed your changes to as the source branch and the master of the DuMu<sup>x</sup> repository
as the target branch. GitLab will usually ask you about opening a merge request if you browse it right after pushing to some branch
* Follow the discussion on the merge request to see what improvements should be done to the branch before merging
* If you have developer status you don't need to do a fork and you can create branches directly
If you have any questions or complaints about this workflow of contributing to DuMu<sup>x</sup>, please ask on the
DuMu<sup>x</sup> mailing list.
## Git
* Use git to your advantage!
* Check out this (great tutorial)[https://www.atlassian.com/git/tutorials/setting-up-a-repository] in order to learn how to use it
* Everything should compile after every single commit
* Make small commits with changes limited to a single issue / change
* Format commit messages as follows
...
...
@@ -16,6 +42,10 @@ the changes the commit introduces and why.
where `topic` is usually a foldername, `[assembly]`, a model `[2p2c]`, or any other topic, e.g. `[cmake]`.
* Use `git rebase -i master` to update branches to the changes on the master branch
* feature branches should be called `feature/my-bla-feature`
* bugfix branches should be called `fix/issue-554`
* cleanup branches should be called `cleanup/remove-deprecated-bla`
* use lower case letters only, and hyphens to separate things
## GitLab
* open issues for bugs / discussions / feature requests
* _Trailing whitespace_: source files may not contain trailing whitespace to reduce the amount of noise in diffs and during merges.
* In contrast to the remainder of the coding style guidelines, these code formatting rules are (partially) enforced automatically with a pre-commit hook. Due to the distributed nature of git, this hook can only check your commits once they arrive in the central repository, so it is important to make your local git repository check your commits as well. The dunecontrol script will automatically install such a pre-commit hook for you.
## C++
### Documentation
...
...
@@ -177,6 +185,14 @@ bool here = true;
* Prefer class templates with regular template arguments over class templates with a `TypeTag` as template argument
### Exception
* The use of exceptions for error handling is encouraged
* There is a variety of DuMux and Dune-specific exceptions you can throw
* All derive (possibly indirectly) from the class `Dune::Exception` in dune-common.
## Files and folders
* Try to order your new header into the existing directory structure
