| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Emailing patches ] | [ Up : Basic Git procedures ] | [ The patch review cycle > ] |
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.
| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Emailing patches ] | [ Up : Basic Git procedures ] | [ The patch review cycle > ] |