| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Lifecycle of a merge request ] | [ Up : Lifecycle of a merge request ] | [ Automated testing > ] |
3.3.1 Uploading a patch for review
Any non-trivial change should be reviewed as a merge request:
https://gitlab.com/lilypond/lilypond/-/merge_requests
Ensure your branch differs from latest master by just the changes
to be uploaded.
Make sure that make, make test and make doc succeed.
Even if the individual commits contain incomplete features, they must
all pass these tests.
Branches pushed on the main repository should start with dev/.
After pushing, create a merge request to start the review cycle. There are multiple options for this as outlined in GitLab’s documentation. This will also ask you for a message that will accompany your patch.
If you are not a member of the team and create the merge request from a fork, consider enabling the box to “Allow commits from members who can merge to the target branch”. This makes it possible for somebody with permissions to rebase your changes and merge them for you. Please refer to Merging to master for more details.
Note: When commenting on GitLab, be careful if you talk about
Texinfo markup. An ‘@’ sign is taken as introducing a
mention. If you leave it without special markup, ‘@foo’
makes the person who has foo as a GitLab username receive
unsolicited notifications. To avoid this, enclose the markup in
backticks: `@lilypond`. For code suggestions, there is
also a dedicated feature, see
the GitLab documentation for information.
| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Lifecycle of a merge request ] | [ Up : Lifecycle of a merge request ] | [ Automated testing > ] |