Gerrit

Learning materials

• https://gerrit-review.googlesource.com/Documentation/intro-user.html
• https://docs.google.com/presentation/d/1C73UgQdzZDw0gzpaEqIC6SPujZJhqamyqO1XOHjH-uk/view

Our installation

Gerrit is at https://gerrit.lix.systems

ssh port 2022

Full URL would be ssh://{username}@gerrit.lix.systems:2022/lix (or https://gerrit.lix.systems/lix if using HTTP auth).

Hit d on any change to download it, which will give you the right URLs.

Workflow tips

Commit history shape

Gerrit is very mean to you if you don't have your commit history in a linear presentable state. Gerrit uses the commit history to get the relations of your changelists, which takes getting used to but it is very low overhead once you get used to it.

Consider not pushing for review before it is clean, or split commits up with git-revise (good) or jj (better) after the fact, amending as you work.

Pushing

The correct way to push to Gerrit is (if your remote is called origin, as it is by default):

git push origin HEAD:refs/for/main

If you get tired of doing this every time, you can automate it by setting the .git/config as follows:

git config remote.origin.push HEAD:refs/for/main

You will have to do that in each fresh check-out. Once it's done, git push will work without additional options.

Pulling

Pulling from Gerrit will work normally. It's worth keeping in mind that sometimes a CL you're working on has been edited in the web UI or by another contributor, so the commit in your repo isn't the latest. Rebasing will usually make the duplicate go away; this is part of the normal rebase semantics, not Gerrit magic. You might consider making rebase-on-pull your default.

Putting purrsonal branches on gerrit

Use refs/heads/sb/USERNAME/*.

CI rerun

Push the CL again with no changes if you want to force CI to rerun.