3.2.6 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 changes are committed in a separate branch, which should differ from the reference branch to be used (usually origin/master) by just the changes to be uploaded. Checkout the branch with the changes:

git checkout some-branch-with-changes

If the reference branch is to be origin/master, ensure that the branch containing the changes is up-to-date with it. Use git rebase or git pull -r to rebase the branch to the head of origin/master. For example:

git pull -r origin master

To upload a patch for review, the changes must be pushed. If you have commit access, this may use a dev/ branch. Otherwise, or at your convenience, you may use a private fork.

Afterwards create a merge request to start the review cycle. There are multiple options for this as outlined in GitLab’s documentation at https://docs.gitlab.com/ee/user/project/merge_requests/. 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.

Revisions

As revisions are made in response to comments, successive patch sets for the same issue can be uploaded by pushing to the same branch. GitLab automatically keeps track of all pushed commits and allows to compare revisions with each other.


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