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.
Topics
A Gerrit topic may be set on push with:
git push origin HEAD:refs/for/main%topic=foo
Which will create all pushed changes with the topic "foo". Topics are helpful for grouping long series of related changes.
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.