3.3.1 Uploading a patch for review

Any non-trivial change should be reviewed as a merge request:


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.

LilyPond Contributor’s Guide v2.25.10 (development-branch).