Gerrit v3.15 contains a lot of interesting additions, this talks presents all the highlights of the new releases, include the AI improvements and stability and security fixes.

• Replicating large (>500k refs) repositories often triggers severe latency bottlenecks when destinations scan all refs to evaluate incoming pushes. By introducing intelligent ref filtering, the plugin evaluates only a subset of refs resulting in same data being replicated, but faster!

• Repairs can now fire automatically (or manually via SSH) when replication encounters missing objects making recovery far less manual than before.

• Single URL failures can no longer break replication. If an endpoint goes down, replication automatically falls back to secondary URLs using a new RoundRobin mode which provides automatic failovers and distributes traffic.

OpenClaw isn’t normally used side by side with “safe”. But it turns out, for the past 15 years OpenDev has been building tools and processes based on Gerrit and Zuul to support safe collaboration between thousands of unknown parties. These tools turn out to be AMAZING at unleashing the potential of systems like OpenClaw, all you have to do is treat your AI agents like untrusted people. What could possibly go wrong?

Using work on the WanderTracks project as an example, we’ll walk through the architecture and approach, showing examples of separate long-lived coding and review agents interacting via the same Gerrit review and Zuul gating system we use for everyone else. We’ll look at the gerrit and zuul plugins for OpenClaw that allow using code review as a communication channels.

It’s not just OpenClaw! Sometimes you want to do the same things with other Agent harnesses, maybe so you can use your Claude Pro Max subscription. We’ll discuss the new spren.bot service that manages agent identities and exposes them to gerrit and zuul via authenticated MCP to allow interacting with them from places like claude.ai safely. Spoiler alert, this works with https://gerrit-review.googlesource.com/ and gerritforge too.

Git introduced few releases ago the multipack index (midx) to maintain performance as the repacking cost grows. We have been implementing multipack index in JGit in fits and starts for a while, but only involved developers seem to know where it stands.

I’ll introduce what are midx and geometric repacking and how do we intend to use them. I’ll explain how did we fit midx in the JGit code, what is currently implemented and how to use it, giving some hints on how development could go from here.

This could be interesting for jgit/gerrit operators interested in enabling midx in their installations and for potential contributors looking for reasonably sized coding opportunities.

Over a decade ago at Google, GerritForge demoed a prototype that demonstrated the immense potential of distributed storage for Git repositories. Today, that vision becomes a reality. This talk introduces a groundbreaking new JGit storage backend built on Apache Cassandra, designed to propel Gerrit and all JGit-based forges firmly into the AI era.

By leveraging JGit’s proven multi-storage capabilities, we have architected a system that decouples repository data to maximise both speed and scale. The solution utilises Cassandra’s flexibility and ultra-fast data transfer rates to handle BLOBs and Packfiles at unprecedented volumes. For pointer management, it seamlessly integrates with our battle-tested global-refdb infrastructure to store Git refs, guaranteeing a highly reliable, multi-primary consistent environment (HA and Multi-Site).

Join this session to explore how this modernised backend solves the massive data and scalability demands of modern machine learning and AI workloads, unlocking the next generation of performance for the Gerrit ecosystem.

When LibreOffice contributors shifted from the old cgit Core browser to Gitiles, they lost search capabilities they had relied on while browsing the repository. Finding commits or searching repository contents increasingly meant switching between Gerrit and local Git commands.

This session follows how that practical LibreOffice problem became an upstream Gitiles contribution. I will cover the incremental path from documenting and testing existing author and committer filters, through git log –grep support, to bounded JGit-backed content search with JSON and HTML interfaces.

I will explain the main design decisions, how Gerrit review shaped the implementation, and how repository traversal is kept manageable for large projects. The session will include a short demonstration and discuss how this work can benefit other Gitiles deployments.

https://gerrit-review.googlesource.com/q/topic:%22gitiles-log-search%22

The session will demonstrate HRT’s custom enhancements to Gerrit as of the time of the session. The content will change based on things that happen between now and then.

As of September 18, 2026. HRT has extended Gerrit across the review UI, CLI, CI, ownership, metadata, and developer tooling to support migration from Phabricator.

Delivered

• Review UI: Stijl, a React frontend with PolyGerrit fallback, adds configurable dashboards, stack visualization, file navigation, comments/suggestions, and integrated checks. Core patches add sticky actions, full-width/auto-expanded diffs, Markdown, syntax highlighting, moved-code detection, Phabricator colors, and review safeguards.
• Review rules: Group reviewers/subscribers, Code Owners views and auto-assignment, plus deployed blocking-reviewer APIs, submit requirements, and UI support.
• CLI: Rust-based gr succeeds cr with arc-compatible diff/land/patch/work/lint workflows, squashed or per-commit uploads, stacked branches, reviewer integration, and paste support.
• CI: Gerrkins replaces key Herald/Harbormaster workflows with event-driven Jenkins jobs, persistent checks, inline lint, patchset reporting, and multiple Jenkins backends. BAT Queue runs directly from Gerrit and Stijl.
• Integrations: Jira, Git-notes APIs, Sourcegraph, custom menus/checker configuration, and Pastes uploads/attachments. Gerrbot is released.
• Platform: Production adoption across DevX and Systems, Phabricator coexistence, faster mirror/ref synchronization, internal build/deployment pipelines, UI CI checks, and the Gerrit 3.14 upgrade with HRT patches preserved.

Ongoing

Gerald’s modular rules engine has a limited cutover; broader Herald-rule migration continues. VS Code review is implemented, with v0 rollout and AI-context integration pending. Other work includes explicit group approvals, muting, auto-submit/auto-queue, release-cadence integration, server-side Jira extraction, and production HA. A unified configuration dashboard is proposed.

An owner’s approval should not become meaningless just because a new patch set arrives. But when does keeping that approval save reviewers from needless repetition, and when does it leave a gap in the ownership policy?

This session is about Sticky Owners: making ownership-based review less mechanical without weakening the checks that matter.

We’ll look at the real questions behind approvals that survive across patch sets and the trade-offs involved in this feature.

If you run OWNERS rules and are tired of asking people to re-approve work they have already reviewed, this should give you practical ideas you can take back to your own Gerrit setup.

Two years ago, the quota plugin was mostly about static namespace limits — capping how many projects or how much disk space a team could use. Today it’s evolved into a full admission-control system for Gerrit’s task queues, built in direct response to a new kind of load: AI coding agents, CI bots, and automation tools (like repo sync -j64) that don’t behave like a human clicking around a UI. They fire concurrent, bursty, high-volume requests that can starve interactive users and even take down a Gerrit instance.

This is as much a case study in incremental, incident-driven system design as it is a feature tour — a small Gerrit plugin quietly becoming critical infrastructure as automated/AI-driven traffic became the dominant load pattern on the server.

Large binary files are a long-standing pain point for Git hosting. Git LFS helps, but it’s a separate tool outside Git, with its own configuration and pitfalls. Over the last few years, upstream Git has gained native building blocks for a different approach: Large Object Promisors. This talk explains how it works and how to use it in practice.

Gerrit performance is not one magic setting. It is the combined effect of version upgrades, hardware choices, plugins, and operational discipline.

This talk presents a practical performance playbook for Gerrit administrators. We will look at what changes when upgrading to Gerrit 3.14.

We will also walk through real tuning examples, including the impact of moving Gerrit workloads from Intel to ARM hardware.

The plugin section focuses on practical tools: Cached RefDB to speed up ref access, git-refs-filter to reduce expensive ref advertisement, and Prometheus metrics to prove whether the changes actually helped.

Attendees will leave with a checklist for making Gerrit faster, measuring the result, and avoiding performance tuning by “gut feeling”.

The JJ team at Google developed a JJ VS Code extension that is used by thousands of engineers internally. See a demo of its UX and its integration with Piper, Google’s internal source control backend. We are currently in the progress of open-sourcing it, and we want it to support Gerrit!

There are many approaches to managing indentation and such in a code base over time. How can a version control system help?

Code review comments, approvals, repo permissions and now agent trajectories and provenance data. All relate to source code and have to be stored somewhere.

Ten years ago, the Gerrit contributors invented NoteDb and pioneered storing metadata alongside source code offering atomic updates, a free audit log as well as easier backup and sync options.

With the SDLC shifting from from human-first to agent-first, new use cases for storing code related metadata have emerged: Provenance and trajectories are just two of many.

In this talk, we’ll go over options that are available today, problems we are thinking about at Google and what lessons we can learn from past design decisions as we evolve our metadata storages.

In this talk, we’ll walk through the philosophy behind JJ, why it works the way it does and the core concepts behind it, we’ll also walk through what it actually took to add native support for JJ change-id headers to Gerrit Code Review. We’ll look at the architectural considerations a modern, Git-based SCM faces when adopting JJ, and how to ensure that JJ and Git users can collaborate seamlessly without stepping on each other’s toes.

Gerrit makes for a great testing ground since it already embraces the patch-set workflow that JJ naturally enables. Even so, bridging the two systems threw some interesting design challenges our way. I’ll share the practical pitfalls we hit and the lessons we learned while making sure we didn’t cause regressions for either user base.

cloud-jj will bring Google’s cloud-backed Commit Cloud server architecture to open source under the Apache 2.0 license. We are planning to develop cloud-jj in public repositories and deliver usable open-source versions by Q3 2027, providing a self-managed Commit Cloud backed by Google Cloud Spanner and Google Cloud Storage that organizations can deploy to handle large repositories, multi-gigabyte binary files, globally distributed teams, and high-concurrency agent workloads.

This talk covers the architecture, components, migration paths, and open-source roadmap of cloud-jj:

• jj Commit Cloud Server: Storing transactional commit graph metadata in Cloud Spanner and bulk content-addressed file and chunk storage in Google Cloud Storage, paired with pluggable authentication, authorization, and per-directory access controls.
• Early and Independent Replication: Streaming modified file contents and tree objects from the workspace to cloud storage in the background before commits are finalized or sent for review, minimizing cross-region replication delays and enabling roaming workspaces across machines.
• Integration and Migration Paths (Native, jj-on-Git, and jj-on-Perforce): Using Commit Cloud exclusively for new projects, or running Commit Cloud on top of existing Git, Gerrit, or Perforce repositories via continuous Git and Perforce indexers that mirror repository history into Commit Cloud with 1:1 Git hash compatibility and push changes back for code review and submission.
• Cross-Platform Virtual File System (jj-vfs): As part of the full cloud-jj stack, mounting writable workspaces in under 200ms across Linux (FUSE3 passthrough), macOS (user-space NFSv4 via Fuse-T), and Windows (ProjFS) to fetch files lazily on demand from Commit Cloud and the local daemon without waiting for large downloads.

The AI revolutionised the way we write software and introduced a new level of workload to the existing CI/CD infrastructure.

The bottleneck is the infrastructure that was built in the past 10 years: how do we ensure that it is able to scale at the same AI pace?

Luca and Jim presents a well-test combination of Gerrit Code Review and Zuul for providing an unprecedented level of scalability and performance that can make your CI/CD infrastructure resilient to the spikes generated by AI agents on a 24/7 basis.

Git has supported SHA-256 repositories since version 2.29, and upstream Git is moving toward making it the default for new repositories. JGit, and with it Gerrit, does not support it yet.

This talk covers:

• Why we need SHA-256 on JGit servers
• What it takes to support SHA-256 in JGit
• How and when the work is heading upstream

It opens with credit to the Git community whose transition design and C Git implementation this work builds on.

Although decentralized Version Control Systems (VCSs) like Git support several organizational structures, a central copy of the repository is typically where development activity is coalesced and where official software releases are cut. Popular practices like AI-accelerated and trunk-based development strain central repositories. Remedial actions, such as performing garbage collection routines, can backfire because they are computationally expensive and if run at an inopportune moment, may degrade repository performance or cause the host to crash.

In this talk, we propose GHS—an automated approach that can take remedial actions to sustain VCS performance. We compare the performance that a VCS can sustain when GHS is applied against a schedule-based garbage collection policy and a no-action baseline. For example, we observe that GHS leads to 64 to 82-fold improvements in the Area Under the Curve (AUC) that plots repository performance over time.

As repositories and development teams grow, Gerrit-triggered build and verification pipelines can become constrained by limited compute capacity, increasing presubmit latency and slowing developer feedback. This session presents a distributed build architecture that dynamically provisions Kubernetes-based workers to execute compilation, testing, linking, and packaging tasks across multiple nodes.

Each remote worker mirrors the required build environment through a shared filesystem, allowing jobs associated with Gerrit changes and patch sets to run consistently across the cluster. The architecture enables two to three times greater task parallelism than traditional single-node builds while preserving the reliability required for code-review and submit-gate workflows.

A key innovation is real-time system-call tracing that records file read, write, and execution activity during remote jobs. This allows the system to identify generated object files, dependency files, test reports, coverage data, and other outputs—even when their locations are not known in advance. File paths and sizes are communicated to the coordinating node, which verifies that all required outputs are synchronized before dependent build or validation tasks begin.

The scheduler uses historical execution statistics to assign work based on task duration, worker performance, and output synchronization cost. Controlled resource oversubscription improves worker utilization, while automatic local retries protect Gerrit verification workflows from remote execution or synchronization failures. Structured JSON logs capture execution metadata for troubleshooting, capacity planning, and build-performance analysis.

The session will demonstrate the Kubernetes architecture, system-call tracing methodology, scheduling model, and integration patterns for Gerrit-triggered validation pipelines. Attendees will learn how to reduce code-review feedback time, scale build capacity dynamically, and improve the reliability and observability of large C/C++ build workflows connected to Gerrit.

Last year the message was: focus the diff. Small, single-concern changes get better, faster reviews. In the meantime coding agents became the industry standard - and they produce Mega-PRs faster than anyone can review them. The GitHub world is catching up: stacked diffs at Meta, Graphite, Sapling, now GitHub’s own stacked pull requests. Gerrit shipped this model years ago: one concern per change, chained for review. What’s missing is the agent part. Agent Skills already teach Claude Code and Codex to plan atomic steps, budget diff size, split branches. All of them PR-shaped. None of them speaks Change-Id. This talk surveys what they converge on, then proposes gerrit-stack: a skill that makes relation chains the agent’s default. Not a cleanup after the fact - the default. Sequel to How to do Code Review like a Pro (https://www.youtube.com/watch?v=7pcb1p3hTtg&t=42s)

Join us for what has become a staple session of the Gerrit User Summit where the maintainers will take questions from the audience! Nothing is off the table, anything from the why a certain features works in a certain way, to where the project is heading next are valid topics!

The maintainers joining in person:

• Martin Fick
• Luca Milanesio
• Fabio Ponciroli
• Antonio Barone
• Kaushik Lingarkar
• Adithya Chakilam
• Nasser Grainawi
• Jacek Centkowski
• Laura Hamelin-Owens