Gerrit

Prerequisites: Intro to Git

Resources

Git (advanced usage) lecture notes

Versioning

Messing with history

Nuclear option for binary files

Setup

Visit gerrit.frc3512.com and sign in / sign up.

Create SSH key pair

ssh-keygen -t rsa -b 4096 -C "your_email@youremail.com"

Add public key to Gerrit

cat ~/.ssh/id_rsa.pub

Copy the entire block, then navigate to the "SSH Public Key" settings of your user settings on Gerrit. Click "Add Key", paste the entire key, then click "Add".

Installing git-review

pacman -S python
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
pip install --user git-review

Configuring cloned repository

git clone ssh://user@gerrit.frc3512.com:29418/Robot-2017
cd Robot-2017
git review -s

Usage

In Gerrit, features are submitted in branches with one commit per branch. Give each branch a name reflecting its content for easier management. Submit new patchsets and revisions of existing patchsets via the following command.

git review

New patchset

Gerrit manages reviews on a per-commit basis. To start a review on a new patch, make sure the commit is on a separate branch from master. Check out that branch and run git review.

Make sure new patchsets are created with git commit. Using git commit --amend will change a commit already merged upstream and lead to conflicts.

Revisions to patchset

Any changes should be incorporated into the commit previously pushed by either amending or rebasing (not pushing a new commit on top of the old one). Gerrit tracks the revisions using the "Change-Id" line at the bottom of the commit message. Make sure this line does not change and remains the last line during commit message modifications. Otherwise, a new patchset will be created instead.

Verify this was done correctly by inspecting the output of git log master..HEAD. There should be only one commit listed and its Change-Id should match the old one.

Uncommitted changes

git commit --amend

Squashing committed changes

If a new commit or commits were made while working, they should be squashed into the first before submitting it all as a new revision. To do so, run

git rebase -i <commit hash before your commits>

The first commit in the resulting generated file should be set to "r" for "reword" if the commit message needs to be altered to include parts of the other two commits. The other commits should be set to "f" for "fixup" so their contents are squashed into the first commit. git rebase descriptions for other options are in the file comment.

To clarify, making a new commit on top of it then running git review will make a new patchset. This is bad practice as the new commit is not a stand-alone feature.

Useful Git features

FAQ

Q: What do I do if no new patchset shows up on Gerrit after running git review?

A: Make sure the remote is set properly. If the gerrit remote doesn't exist, run git review -s to add it. Otherwise, run git remote -v to list the available remotes. To change a remote such as gerrit, run git remote set-url gerrit SSH/URL.

Q: How do I push the same patchset to a different repository?

A: Change the gerrit remote to point to the new repository with git remote set-url gerrit SSH/URL, then run git commit --amend and delete the Change-Id line before saving the commit message. Running git review after that will create a new patchset for that commit.

Since commit hashes change after rebasing, Gerrit uses Change-Ids to match up new commits with their corresponding patchset. When a commit is made without a Change-Id, a new one is generated automatically and will show up as a new patchset when pushed to Gerrit with git review.