How to contribute
Contents
Warning:
This page needs revision. Some of the information in the page may be deprecated.
Pre-requisites
In the following we will assume you successfully
- followed the Getting started guide,
- (Optional) Configured your git environment.
- Cloned the repository.
Upload your contribution
Using git push =
1. To avoid merge conflicts, it is recommended to do a pull with rebase before pushing your contribution in order to merge latest changes made by other users.
git pull --rebase
Note: you can force git to use always the --rebase option with:
git config --local pull.rebase true
2. Push your commits to Gerrit for Code Review using the following command:
git push origin HEAD:refs/for/master #use 'v1.0' instead of 'master' for contributing to v1.0 branch
Note: you can also configure git to push always to the desired branch.
git config --local remote.origin.push HEAD:refs/for/master git config --local remote.origin.push HEAD:refs/for/v1.0
3. Enter your username.
4. Enter your password.
5. You can review your contribution on Gerrit web interface
Notes:
- The following actions are execution automatically after pushing any contribution to Gerrit:
- Gerrit reports the new contribution state to the corresponding bug in Bugzilla
- Gerrit notifies Jenkins to build the new contribution.
Push your contribution to Gerrit using git review
Instead of using "git push", you could use "git review". Follow this guide (Using git-review to push and review changes) to install and configure git-review. You will also have to set the SSH URL for your remote and copy the commit-msg hook.
- To avoid merge conflicts, it is recommended to do a pull with rebase before pushing your contribution.
git pull --rebase
- Then, send your contribution to gerrit:
git review -c
Gerrit Notifications
Gerrit sends email notifications to:
- Owner of the change
- Reviewers of the change
- Project watchers
Each user can configure his own watched projects and branches in the "settings/watched project" menu. Email notifications can be sent for New Changes, New Patch Sets, All Comments, Submitted Changes and Abandoned Changes.
Link: https://osm.etsi.org/gerrit/#/settings/projects (you can navigate there from the Gerrit console by clicking on the arrow by your login on the top right corner)
Continuous Integration
- Jenkins builds, tests the new contribution, and reports the result on its web interface.
- Jenkins votes on the contribution using “Code-Verif” (-1, +1) on Gerrit.
Code Review
- Other contributors and MDG Committers can comment the new contribution and vote using “Code-Review” (-1, 0, +1) on Gerrit.
- The MDG Leader can comment the new contribution and votes using “Code-Review” (-2, -1, 0, +1, +2) on Gerrit.
Amending a contribution in Gerrit
Before amending, make sure that you have the commit-msg hook installed in your local repo. For instance, if your user is "user" and the repo is the "devops" repo, the command to install the commit-msg hook would be:
$ scp -p -P 29418 user@osm.etsi.org:hooks/commit-msg devops/.git/hooks/
In that way, all patches will use the same Change Id, thus guaranteeing that they will be associated to the same change.
Amending your last change/commit pushed to Gerrit
1. Fix the code.
2. Add all updated files to the index.
git add <file>
3. Amend your commit. NOTE: Don't use the -m flag to specify a commit message, since it will override the previous message and regenerate the Change-Id. Instead, use the text editor to change the commit message if needed, and keep the Change-Id line intact.
git commit --amend
4. Submit your change back to the repository. NOTE: use the appropriate branch instead of master, if you are working on a different branch.
git push origin HEAD:refs/for/master
Amending one of your changes which has dependencies on subsequent changes
This procedure will only work if you are the only person working on a set of commits and you don't expect others to push commits and rebase them to be dependent on yours.
1. Run 'git status' on the branch to know how many commits you are ahead of origin. NOTE: use the appropriate branch instead of master, if you are working on a different branch.
git status On branch master Your branch is ahead of 'origin/master' by 3 commits.
2. Do an interactive rebase over the last X commits and specify which commit you want to amend by changing the command of the commit from "pick" to "edit".
git rebase -i HEAD~3 edit 0ab17ad Change in file1 pick 4995f46 Second change pick baa85bf Third change
3. Fix the code in the commit, add the files, amend the commit, and continue rebasing:
vi file1.txt #Fix the code git add file1.txt git commit --amend git rebase --continue
4. In case of conflicts with subsequent commits, you will have to solve them, and continue rebasing
vi file1.txt #Fix the conflict git add file1.txt #Add the files to the staging area; no commit is required. git rebase --continue
5. Repeat step 4 as many times as required, until rebase finishes.
6. Push your changes to gerrit. NOTE: use the appropriate branch instead of master, if you are working on a different branch.
git push origin HEAD:refs/for/master
Amending a change of another author using git
When amending code from a different author, reviewer and original author should be coordinated in order to make sure that changes made by the reviewer are not reverted by the original author later. For that reason, it is recommended to avoid using the local copy of the branch. Instead, it is recommended to create a new local branch to work on every specific change, following the procedure below:
1. Get the last code from the repository.
git fetch origin
2. Create a new branch to work on the code from the remote branch. You can use the review number and patchset as name. NOTE: use the appropriate branch instead of master, if you are working on a different branch.
git checkout -b <review-number>-<patchset> origin/master
3. Pull the patch on the created branch. (To find the command to execute you can open the corresponding change page on Gerrit UI, click on download menu, then copy the "pull" command.)
git pull <url> <ref>
4. Fix the code.
5. Add all updated files to the index.
git add <file>
6. Amend the commit. NOTE: Don't use the -m flag to specify a commit message, since it will override the previous message and regenerate the Change-Id. Instead, use the text editor to change the commit message if needed, and keep the Change-Id line intact.
git commit --amend
7. Submit your change back to the repository. NOTE: use the appropriate branch instead of master, if you are working on a different branch.
git push origin HEAD:refs/for/master
Amending a change of another author using git-review
1. Follow the instructions in this link to install and configure git-review.
2. Download the change with git-review
$ git review -d 1280 Downloading refs/changes/80/1280/1 from gerrit Switched to branch "review/garciadeblas/1280"
This will download the change, put it in a branch called review/AUTHOR/change (if the change has no tag, the sequence number will be used instead), and switch to that branch.
3. After that, you can amend the downloaded change to improve it. Finally, push it again:
$ git add # add the changes $ git commit --amend # do not touch the Change-Id. The Change-Id is the way for gerrit to keep track what belongs to what development stream as a new patch set. $ git commit --amend --author # if you want to mark the changes as yours. $ git review -c -R # The -R is important, since it tells git-review to not rebase your change against master.
NOTE: Don't use the -m flag to specify a commit message, since it will override the previous message and regenerate the Change-Id. Instead, use the text editor to change the commit message if needed, and keep the Change-Id line intact.
4. Delete the branch once you have finished:
$ git branch -D review/garciadeblas/1280
Merging the contribution
- The MDG Leader can "Submit" the change only if +1 "Code-Verif" (from Jenkins) and at least one +2 "Code-Review".
- Gerrit reports the result of the code review to the corresponding bug in Bugzilla