3. Git and GitLab



The source code is hosted at the Max–Planck–Institut für Eisenforschung at the GitLab server magit1.mpie.de. You need an account to access the repository.


Set up Git on your computer such that GitLab can recognize you:
> git config user.name "FIRSTNAME LASTNAME"
> git config user.email "A@B.DE"
in the DAMASK repository or
> git config --global user.name "FIRSTNAME LASTNAME"
> git config --global user.email "A@B.DE"
for a system-wide setup.

development is the branch that is should always work (and release / master of course as well) For any changes, create a new branch named after the feature you're working on (or, contribute to an existing branch). For new features, create tests.

After finishing working on a brach, test the code. If it is working, request to merge it into development. Assign the merge request to one of the developers (that is not you!)

For a small bugfix to the latest commit, use git commit --amend


Workflow model

In contrast to centralized version control systems such as SVN, their distributed counterparts offer a lot of flexibility in selecting a workflow model. https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow presents some possible workflows. A detailed discussion, including many links, can be found on http://stackoverflow.com/questions/2621610/what-git-branching-models-work-for-you

  • DAMASK work flow
    • DONE Create a new branch for features and improvements
    • DONE Once all changes are done, request to merge them into the development branch
    • DONE After a successfull test, development is automatically merged into master
    • DONE Releases are manually created from the master branch (release branch)



Tags are used to mark certain revisions. Releases are marked by tags. Read this German text or check out semver.org

DAMASK G MM.mm.ff.pppp
^^^^^^--------------------------- Name
       ^------------------------- Generation (skip for the moment until we have DAMASK 2)
         ^^---------------------- Major (not backward compatible, old input files will not work)
            ^^------------------- Minor (new features)
               ^^---------------- Bugfix
                  ^^^^----------- Patch


Correctness Checks

For a fast feedback on any changes pushed to the http://magit1.mpie.de, modified files are checked before a push is accepted. This is done via a pre-receive hook.

Python files are checked for invalid code, unused variables etc using prospector. Prospector is a tool to analyze Python code and output information about errors, potential problems, convention violations, and complexity and combines the functionality of other Python analysis tools. The configuration file DAMASK.yaml is designed to ensure compatibility with Python 2.x and Python 3.x.

Any change in the src subdirectory triggers a syntax check with Gfortran -fsyntax-only for the spectral solver; Any change in the src subdirectory triggers a syntax check with Ifort -fsyntax-only for MSC.Marc.

To skip this check, add '[skip sc]' to the latest commit message, e.g. via
> git commit -a --amend
in the case that all your changes are locally committed already.



Extended testing is performed on each push using the GitLab Continuous Integration. All tests specified in a configuration file in the main repository are run on the test server (nohup, using Damask_user). The pipelines give a feedback, which tests are working.

To skip the tests, add '[skip ci]' to the latest commit message, e.g. via
> git commit -a --amend
in the case that all your changes are locally committed already.

If the test suite needs to be modified for a certain branch, the submodules feature of git allows to couple the status of the branch with a fitting commit in the PRIVATE repository.

Initialize (i.e. clone) the PRIVATE repository via
> git submodule update --init
Any change in PRIVATE needs to be commited/pushed as usual. As submodules are linked as commit IDs (hashes) and not as branches, after initialization you are in 'detached head' mode and need to check out the branch of interest (typically 'master'). Additionally, commit the current commit ID of the PRIVATE repository in the DAMASK repository:
> git commit PRIVATE
By that, the status (i.e. the current commit ID) is stored in the current branch of the DAMASK repository and will be used by the test facility.


This topic: Development > WebHome > UsingGit
Topic revision: 05 Feb 2021, FranzRoters
This site is powered by FoswikiCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding DAMASK? Send feedback
§ Imprint § Data Protection