Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
This guide explains how to contribute code to a Linux Foundation (LF) Gerrit repository: set up access, submit a patch for review, update it without creating a second review, and handle common rebase and CI problems. It is based on the LF Release Engineering Gerrit Guide. Use the clone command and branch name shown by your own project; the LF documentation repository commands below are examples, not universal settings.
How Gerrit works
In the LF workflow, you normally push a commit to Gerrit for review rather than push directly to the project’s main branch. Gerrit holds the discussion, review votes, automated checks, and submission decision around that proposed change. The project’s authorized committer or submit rules determine when it can be merged.
| Term | Meaning |
|---|---|
| Commit | A Git object containing a snapshot and commit message. |
| Branch | A named line of development in Git. |
| Change | A Gerrit review, generally tracked by its Change-Id and change number. |
| Patchset | An uploaded version of a change. Updating the same commit while preserving its Change-Id normally creates a new patchset on the existing review. |
| Topic | An optional Gerrit grouping for related changes; it does not itself establish dependencies or guarantee atomic merging. |
A Gerrit change is therefore not simply a branch or a GitHub-style pull request. The crucial distinction for contributors is: create a new commit and Change-Id for a new review; amend the existing commit and retain its Change-Id to update that review.
Before you begin
- An LFID (Linux Foundation ID) with access to the project’s Gerrit instance.
- Git, and a configured Git name and email matching the identity associated with your LFID account. The LF guide notes that capitalization matters.
- SSH key access or the project’s supported authenticated HTTPS method.
git-reviewis recommended for the documented contribution workflow.- For projects using the documented LF convention, a DCO sign-off on each contribution.
Set your Git commit identity and preferred editor if needed:
#1 Best Overall
git config --global user.name "Firstname Lastname"
git config --global user.email "[email protected]"
git config --global core.editor "text-editor-name"
git config --get user.name
git config --get user.emailThese Git settings are commit metadata, not your Gerrit login. Keep the identities distinct: LFID username authenticates you, an SSH key or HTTPS credential grants access, and Git name/email appear in commits and should match your Gerrit account as required by the guide.
Choose SSH or HTTPS
| Method | Good fit | Trade-offs |
|---|---|---|
| SSH | Regular contributors whose network allows Gerrit SSH. | Requires registering an SSH public key; Gerrit’s SSH port, often 29418 in the LF example, may be blocked by a firewall. |
| Anonymous HTTPS | Read-only browsing or cloning where the repository allows it. | It does not permit uploading changes. |
| Authenticated HTTPS | Contributors behind an SSH-blocking proxy or firewall. | Requires a Gerrit HTTP password or other credential supported by that deployment, and careful credential handling. |
The LF guide recommends SSH for contributors, but availability and policy vary by repository. For SSH, register the public key in your Gerrit account and confirm authentication with the project’s host and settings. For HTTPS uploads, generate credentials using the current Gerrit interface for that deployment. Older Gerrit pages may call this an “HTTP Password”; the label and credential model can differ today. Never put a password or token in a shell command that will remain in history, a committed file, or a shared script.
Clone the actual project repository
- Open the repository in the project’s Gerrit instance and go to its General page.
- Select SSH or HTTPS and copy the generated clone command.
- Clone and verify the remote:
git clone <copied-clone-command>
cd <repository-directory>
git remote -vFor reference, the LF guide uses this SSH example for its own documentation repository:
git clone ssh://[email protected]:29418/releng/docsDo not substitute that URL blindly. LF projects can differ in host, context path, repository name, target branch, and access policy. Anonymous HTTPS is read-only; an authenticated HTTPS clone URL may include a context path and must come from the repository’s own Gerrit page.
Install git-review and the Change-Id hook
Install git-review using your operating system’s package manager when a suitable package is available. A virtual environment is another option if the system package is unavailable or too old:
virtualenv ~/.virtualenvs/git-review
~/.virtualenvs/git-review/bin/pip install git-review
~/.virtualenvs/git-review/bin/git-review --versionMake sure the environment’s executable is on your PATH, or invoke it by full path. The Change-Id hook is separate from git-review: it adds a Change-Id: footer to commit messages so Gerrit can associate later revisions with the same review. The LF guide documents downloading it over SSH or HTTPS; use the route supported by your server:
# SSH example; run from the repository root
scp -p -P 29418 [email protected]:hooks/commit-msg .git/hooks/commit-msg
# HTTPS example for the LF documentation Gerrit context path
curl -Lo .git/hooks/commit-msg https://gerrit.linuxfoundation.org/infra/tools/hooks/commit-msg
chmod +x .git/hooks/commit-msgHook paths are deployment-specific. Confirm the correct host and path in the target Gerrit documentation or repository instructions. After making a commit, check that its message contains a Change-Id: footer:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
git log -1 --format=fullIf the hook is missing, non-executable, installed in another repository, or installed after a commit was made, amend that commit after fixing the hook. Disabling Change-Id generation with git config gerrit.createChangeId false is generally not appropriate for a normal Gerrit contribution unless your project explicitly documents another workflow.
Submit your first change
First confirm the project’s target branch in its instructions or Gerrit. The LF guide uses master in examples, but a repository may use main, a release branch, or another development branch.
git fetch origin
git switch -c my-feature origin/<target-branch>
git branch --show-current
git log -1 --onelineMake the change, inspect what you intend to submit, stage only the relevant files, and commit with DCO sign-off when the project requires it:
git status
git add path/to/file
git diff --cached
git commit -s-s adds a Signed-off-by: line, the DCO attestation described in the LF environment overview. It is not the same as cryptographically signing a commit with GPG or SSH. Nor is it the Gerrit Change-Id, or a Code-Review/Verified vote; those have separate purposes.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Submit the commit for review:
git reviewgit-review normally sends the current commit to Gerrit’s review destination rather than directly updating the branch. If it is unavailable or misconfigured, the raw Git equivalent is:
git push origin HEAD:refs/for/<target-branch>Replace the branch with the repository’s actual target. refs/for/<branch> requests review; pushing to refs/heads/<branch> is a different operation and may be permitted only for users with elevated permissions. Do not try to bypass review unless the project explicitly authorizes it. To group related changes under a topic, the LF guide also documents:
git review -t my-topicA topic is organizational, not a substitute for making dependencies clear to reviewers.
After the upload
Open the Gerrit URL printed by the push and verify that the change is in the intended project and target branch, and that it represents the commit you meant to submit. Review the Change-Id and change number, then watch the discussion and automated checks. Add reviewers or mark the change ready according to the project’s conventions.
Free tools Windows power users keep installed
One-click scans. No signup required.
Gerrit deployments differ in how they represent unfinished work. The LF guide includes older references to draft changes, self-voting, putting “WIP” in a commit message, and adding Jenkins as a reviewer. Treat those as historical or deployment-specific, not universal current controls. Use the current change page’s work-in-progress or draft controls if available, and do not assume that marking a change unfinished suppresses every CI job. If checks do not run, consult the project’s trigger and recheck instructions.
Understand review votes and merge readiness
- Code-Review is a human review label; its values, permissions, and required threshold vary by project.
- Verified commonly records an automated build or test result, but the label and criteria are deployment-specific.
- Workflow or other labels may reflect project-specific process rules.
- Negative votes may block submission, and a vote can be tied to a particular patchset; a newer patchset may require renewed review or checks.
The LF guide describes a typical pattern involving reviewer approval, no blocking negative votes, a committer approval, and a committer submitting the change. Do not assume this is uniform across LF repositories: labels, thresholds, required checks, branch protections, dependencies, and submit rules are configured per project. If Gerrit says a change cannot submit despite approvals, inspect its labels and status rather than assuming the vote count alone is decisive.
Update an existing review
To revise your own change, retain the original Change-Id and amend the existing commit. This is what tells Gerrit to create a new patchset on the same review instead of a second change.
git status
git show --stat
# Make and stage your edits
git add path/to/file
git commit --amend
git log -1 --format=full
git reviewCheck the amended message before uploading: the original Change-Id: should still be present. If you intentionally want a separate review, create a separate commit with its own Change-Id instead. The guide also documents fetching a change by its Gerrit change number:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsgit review -d CHANGE_NUMBERThis may create or switch to a local review branch. Check git status first so you do not lose uncommitted work. If the change belongs to someone else, do not amend and upload it without permission or the project’s established convention; preserve attribution and verify author and committer details.
Dependent changes and stacked reviews
When one change depends on another, make the relationship visible in Gerrit and to reviewers. The LF guide documents downloading a parent, applying a child, and submitting the stack with git-review options:
git review -d PARENT_CHANGE_NUMBER
# Apply or cherry-pick the dependent commit, then make any needed edits
git review -x CHILD_CHANGE_NUMBER
git review -RExact option behavior depends on the installed git-review version and server configuration; check its help if the command does not behave as expected. A child change may not merge before its parent. Rebasing the parent can require updating children, and large stacks add review and conflict complexity. Make clear which changes can merge independently; topics group changes but do not make them atomic.
Rebase safely and resolve conflicts
Fetch the current target branch before rebasing your work. Replace master below with the actual branch. If you are updating an existing change, first check out its review branch, for example with git review -d CHANGE_NUMBER.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11git fetch origin
git rebase origin/<target-branch>If Git stops on conflicts, inspect the status, resolve each listed file, and stage only the files you have intentionally resolved:
git status
# Edit conflicted files and remove conflict markers
git add path/to/resolved-file
git rebase --continueRepeat as needed. If you need to return to the pre-rebase state:
git rebase --abortAfter a successful rebase, confirm the commit message still has its Change-Id, then upload the updated patchset with git review. Avoid broad commands such as git add * during conflict recovery: they can stage unrelated files. If Git reports an empty commit, check whether the change was already incorporated before deciding how to proceed.
HTTPS-only setup for the LF example
The LF guide gives a specific HTTPS configuration for its documentation repository. Its project path and context path are not universal:
git config gitreview.scheme https
git config gitreview.port 443
git config gitreview.project infra/releng/docs
git review -sUse the actual host, project path, and context path for your repository; LF Gerrit paths can differ. If using a ~/.netrc file for credentials, restrict access to your account:
chmod 600 ~/.netrcDo not commit the file or expose its contents in logs. The LF page notes that manually fetching the hook may be needed with some git-review versions; treat that as version-dependent, and verify that the hook is executable in the repository you are working in.
Troubleshooting by symptom
Cannot clone or authenticate
- Confirm you copied the URL from the target repository’s Gerrit General page and selected the intended protocol.
- For SSH, check that the public key is registered, the expected key is loaded, and the network permits the SSH port. The LF example uses port 29418.
- For HTTPS, verify the username, current credential method, scheme, port, and Gerrit context path. Anonymous HTTPS cannot upload.
- Confirm your LFID account and project permissions are active.
- Useful checks include
git remote -vand, for the LF SSH example,ssh -p 29418 [email protected]. Gerrit may deny interactive shell access while still confirming authentication.
Push says there is no Change-Id
Install the correct commit-msg hook in this repository, make it executable, and amend the commit:
chmod +x .git/hooks/commit-msg
git commit --amend --no-edit
git log -1 --format=fullIf needed, retrieve the hook from the correct server-provided path; the LF example is:
curl -Lo .git/hooks/commit-msg https://gerrit.linuxfoundation.org/infra/tools/hooks/commit-msg
chmod +x .git/hooks/commit-msgA second Gerrit change appeared unexpectedly
Inspect the commit message and history with git log --format=full. A changed or missing Change-Id, or creating a new commit instead of amending, can cause Gerrit to treat an upload as a different review. To update the original review, amend the intended commit and retain its original Change-Id before uploading.
The patch targets the wrong branch
Check the project’s target branch, fetch remote refs, rebase onto the correct branch, and submit to refs/for/<correct-branch> (or configure git-review accordingly). Do not assume master.
CI did not run or the change cannot merge
Check whether the change is marked work in progress, whether project trigger rules exclude the affected paths, whether a required label or reviewer is missing, and whether CI is available. For a blocked submission, also check stale votes, negative labels, merge conflicts, dependencies, and project-specific submit rules. There is no single recheck command or universal set of labels for all LF projects; follow the repository’s current instructions.
For Gerrit administrators
Contributor commands do not configure repositories, access-control lists, replication, submit rules, or Gerrit services. Those elevated tasks are covered separately in the LF infrastructure Gerrit guide, which includes replication and repository administration. Do not run administrative commands or alter project rules unless you have the required role and authorization.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The contributor workflow above is based on the official LF Release Engineering documentation. Its Gerrit page includes legacy terminology and deployment-specific examples; the target repository’s current UI and project instructions take precedence where they differ.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
