Item — HN Reader

Gerrit has had the concept of "draft" for a long time. It's also better at multiple "patchsets" as a "changelist" evolves, some of which can have rebasing without needing a forced update. On the other hand, it's somewhat hacky the way it layers on top of git, requiring a "change id" to link the different patchsets together. Much of the way it works came from trying to deliver a similar experience as Perforce.

Disclosure: worked at Google, have used both systems a lot.

1 comments

I found a small inconvenience of maintaining ChangeId (usually handled automatically by the git hook) a very small price to pay for all great features provided by Gerrit. I know that Gerrit team investigated few times a better way to attach this metadata to commits but so far it works this way.

What other 'hacky ways' you mean? 'Magic' refs/for/* branches can be a bit weird at beginning. On the other hand introducing Gerrit 7-8 years ago to my back-then employer made me understand the Git model much better. Anyway, e.g. IntelliJ IDEA plugin for Gerrit should alleviate almost all pain points (if someone stick to JetBrains products).

Were you working on Android/AOSP? I always assumed that this is the primary project where Googlers have a chance to work with Gerrit. I thought that Google uses some in-house CR system, as mentioned by https://www.gerritcodereview.com/about.html.

Yes, Android then Fuchsia. I agree it's good, overall I prefer it to Github, but by "hacky" I mostly mean it's very much out of step from the way the rest of the ecosystem works. This is much more true for repo / jiri (which is Google's own spin on the submodule problem), but includes change ids.