Maintenance will be performed on,,, and tomorrow, 2020/08/04, starting at approximately 9am PDT. It is expected to take around 15 minutes and there will be a short period of downtime towards the end of the maintenance window. Please direct any comments, questions or concerns to 6.99 KB
Newer Older
1 2
# Contributing to LALSuite

Adam Mercer's avatar
Adam Mercer committed
This page outlines the recommended procedure for contributing changes to the LALSuite repository. Please read the introduction to [GitLab on]( before you start. 
4 5 6 7 8 9 10 11 12 13

## Reporting Issues

When reporting issues, please include as much detail as possible to reproduce the error, including information about your operating system and the version of each (relevant) component of LALSuite.
If possible, please include a brief, self-contained code example that demonstrates the problem.

## Contributing code

All contributions to LALSuite code must be made using the fork and [merge request]( [workflow](, which must then be reviewed by one of the project maintainers.

If you wish to contribute new code, or changes to existing code, please follow this development workflow:
15 16 17 18 19

### Make a fork (copy) of LALSuite

**You only need to do this once**

Adam Mercer's avatar
Adam Mercer committed
1. Go to the [LALSuite repository home page](
Adam Mercer's avatar
Adam Mercer committed
2. Click on the *Fork* button, that should lead you [here](
3. Select the namespace that you want to create the fork in, this will usually be your personal namespace
23 24 25 26 27

If you can't see the *Fork* button, make sure that you are logged in by checking for your account profile photo in the top right-hand corner of the screen.

### Clone your fork

Adam Mercer's avatar
Adam Mercer committed
Make sure that you have installed and configured [git-lfs]( for the management of large files. This is required to successfully build and install your development fork. 
29 30 31

Then, clone your fork with 

git clone<namespace>/lalsuite.git
34 35

### Keeping your fork up to date

Link your clone to the main (`upstream`) repository so that you can `fetch` changes, `merge` them with your clone, and `push` them to your fork. Do *not* make changes on your master branch. 
39 40 41 42 43 44 45 46

1. Link your fork to the main repository:

    cd lalsuite
    git remote add upstream

47 48 49
   You need only do this step once. 

2. Fetch new changes from the `upstream` repository, merge them with your master branch, and push them to your fork on
50 51

    git checkout master
    git fetch upstream
54 55
    git merge upstream/master
    git push
56 57

3. You can see which remotes are configured using

60 61 62
   git remote -v

   If you have followed the instructions thus far, you should see four lines. Lines one and two begin with `origin` and reference your fork on with both `fetch` and `push` methods. Lines three and four begin with `upstream` and refer to the main repository on with both `fetch` and `push` methods.

66 67 68
### Making changes

All changes should be developed on a feature branch in order to keep them separate from other work, thus simplifying the review and merge once the work is complete. The workflow is:

1. Create a new feature branch configured to track the `master` branch of the `upstream` repository:

72 73 74 75 76 77 78
   git checkout -b my-new-feature upstream/master

   This command creates the new branch `my-new-feature`, sets up tracking the `upstream` repository, and checks out the new branch. There are other ways to do these steps, but this is a good habit since it will allow you to `fetch` and `merge` changes from `upstream/master` directly onto the branch. 

2. Develop the changes you would like to introduce, using `git commit` to finalise a specific change.
79 80
   Ideally commit small units of change often, rather than creating one large commit at the end, this will simplify review and make modifying any changes easier.

   Commit messages should be clear, identifying which code was changed, and why.
82 83 84
   Common practice is to use a short summary line (<50 characters), followed by a blank line, then more information in longer lines.

2. Push your changes to the remote copy of your fork on
   The first `push` of any new feature branch will require the `-u/--set-upstream` option to `push` to create a link between your new branch and the `origin` remote:
86 87

    git push --set-upstream origin my-new-feature
90 91

    Subsequenct pushes can be made with 
92 93

    git push origin my-new-feature
96 97 98 99 100 101 102
3. Keep your feature branch up to date with the `upstream` repository by doing 

   git checkout my-new-feature
   git fetch upstream
   git rebase upstream/master
Patrick R Brady's avatar
Patrick R Brady committed
   git push -f origin my-new-feature
104 105 106 107 108

   This works if you created your branch with the `checkout` command above. If you forgot to add the `upstream/master` starting point, then you will need to dig deeper into git commands to get changes and merge them into your feature branch. 

   If there are conflicts between `upstream` changes and your changes, you will need to resolve them before pushing everything to your fork. 
109 110 111 112 113

### Open a merge request

When you feel that your work is finished, you should create a merge request to propose that your changes be merged into the main (`upstream`) repository.

114 115
After you have pushed your new feature branch to `origin`, you should find a new button on the [LALSuite repository home page]( inviting you to create a merge request out of your newly pushed branch. (If the button does not exist, you can initiate a merge request by going to the `Merge Requests` tab on your fork website on and clicking `New merge request`)

You should click the button, and proceed to fill in the title and description boxes on the merge request page.
117 118 119 120 121 122 123 124 125
It is recommended that you check the box to `Remove source branch when merge request is accepted`; this will result in the branch being automatically removed from your fork when the merge request is accepted. 

Once the request has been opened, one of the maintainers will assign someone to review the change. There may be suggestions and/or discussion with the reviewer. These interactions are intended to make the resulting changes better. The reviewer will merge your request.

Once the changes are merged into the upstream repository, you should remove the development branch from your clone using 

git branch -d my-new-feature

A feature branch should *not* be repurposed for further development as this can result in problems merging upstream changes. 

129 130 131 132 133 134
### Special case: CW codes in LALPulsar and LALApps

For the continuous-wave (CW) related codes in the `lalpulsar/` and `lalapps/src/pulsar` directories,
issues should preferentially be reported [in the CW fork tracker](
Branches in that fork can also be used for short-term development, please also see the special contributing guide [here](

135 136 137
## More Information

More information regarding the usage of GitLab can be found in the main GitLab [documentation](