Gerrit integration for sync/submit?

[ComputerDruid]

Gerrit is a code review system serving a similar role as GitHub Pull Requests, but the workflow is different.

Gerrit asks you to install a commit hook which adds a Change-Id: footer (picked randomly for new commits) to each commit. Then any commit you upload via git push gerrit SOME_COMMIT:refs/for/main gets uploaded as a seperate "change list" (CL) in the gerrit UI. Uploading a new commit with the same Change-Id overwrites the existing one by creating a new "patchset" (numbered by the number of times the CL has been uploaded).

If you push a branch with multiple commits, they each get uploaded as a chain of dependent CLs.

This already works really well with the git-branchless model, since handles dependent CLs in a very similar way as git-branchless, and git-branchless can help automate restacking after editing a commit higher in the chain.

I still think the integration could be improved in a couple of major ways:

1. git branchless submit should be able to do the git push to refs/for/main (or whatever the desired branch is called) for all relevant commits

2. The should be some way of downloading updated patch sets from gerrit if a CL was updated on another computer or by another collaborator. As an example, I've been using managing a chain of commits with git-branchless, and had uploaded patchset 4 of https://fxrev.dev/797262 . David Koloski then helped me out by fixing some stuff in the CL that needs to be done before it can be submitted, and uploaded patchsets 5 and 6. In order to rebase the stack, I had to do some manual steps to git fetch https://fuchsia.googlesource.com/fuchsia refs/changes/62/797262/6, unhide FETCH_HEAD, restack the later commits on top of this new FETCH_HEAD, then hide the original commit that had been uploaded as patchset 4. It would be nice if there were a way to manually mark that commit as a successor to the original commit (the way amend does), and it would be even better if there were a way to automatically fetch the newest version of each CL automatically (perhaps with git branchless sync)

Caveat: this explanation of "how gerrit works" is mostly informed by my experience contributing to the Fuchsia project. This really is how gerrit works on the Fuchsia project, but I believe it's possible to configure gerrit to work slightly differently; I think you can make the Change-Id footer optional rather than mandatory, for example. And it's possible to enable something called "topics" which make it possible for multiple commits to land together rather than each getting its own review and landing separately. So to be perfect it might need to be more tunable than just fit this specific workflow, although I think just handling this configuration might be a good place to start.

[ComputerDruid]

Some implementation notes that I think might be useful for implementing the syncing feature:

you can query for the latest (and previous) patchsets of a change by using git ls-remote:

$ git ls-remote https://fuchsia.googlesource.com/fuchsia refs/changes/62/797262/'*'
f5114db58bb38a9cba42a26bd4ae7452dffb7975        refs/changes/62/797262/1
b1c8039c8f7860c8dd3c2e2676c99da23e163ecd        refs/changes/62/797262/2
e770e7acfef149b5c4133137cce5bfd98abe25d7        refs/changes/62/797262/3
42209af31823795b489f172fd7491eeafefb4481        refs/changes/62/797262/4
8f16af8c8c7fc13f20275fcf418e8db105c2f5a5        refs/changes/62/797262/5
d6859916f684cbb57bc43387d4dca9bbfdd29ed1        refs/changes/62/797262/6
0d9b0ab371f012e7d7599c518c7adbe8da8d98de        refs/changes/62/797262/meta
d45f670f80ae1268395c0da6c438d5c01f9bf78f        refs/changes/62/797262/robot-comments

Although you have to know the "change number" that gerrit picked for the CL. (I believe that is just an incrementing number as CLs are created). The "shard bucket" thing there is just a repeat of the last 2 digits of that number.

One way to look up the "change number" with just the Change-Id is to use the gerrit REST API:

# Look at the Change-Id in the commit from patchset 4, there
$ git cat-file -p 42209af31823795b489f172fd7491eeafefb4481 | grep Change-Id
Change-Id: Ibc41c6ac63813be9eaecdc0250f3135e5d346286
$ curl https://fuchsia-review.googlesource.com/changes/Ibc41c6ac63813be9eaecdc0250f3135e5d346286 |tail -n +2 | jq ._number
797262

Although that's admittedly made easier by the fact that fuchsia's gerrit is a public instance; if you needed to authenticate that would be a bit harder.

[arxanas]

I started support for customizable Git hosting providers ("forges"). For example, you can see the Phabricator work in progress here: #866. You could add a Gerrit forge with your implementation.

Phabricator uses a de-facto change ID via the Differential Revision: https://phabricator.example.com/D12345 field in the commit message, which is inserted by the arc tool as part of the upload step. (It should be easier to handle the change IDs in Gerrit because the change IDs are generated earlier in the process, and you don't have to amend commits with newly-generated change IDs.)

In order to rebase the stack, I had to do some manual steps

It might be easiest to do git fetch XXX && git reset XXX && git amend --merge.

and it would be even better if there were a way to automatically fetch the newest version of each CL automatically (perhaps with git branchless sync)

Phabricator has a dedicated command to check out the newest version of each CL (arc patch). Usually, it suffices for me to do that (and, if necessary, I can rebase other commits on top of the newly-checked out commit). Handling bidirectional information flow (both uploads and downloads) is hard 🙂.

[ComputerDruid]

Thanks for the info! I won't immediately try to do that but I may come back to this in the future if it keeps bugging me. I really appreciate the pointers regardless