On Fri, Jul 14, 2017 at 7:27 AM, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote: > On Thu, Jul 13, 2017 at 8:11 PM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote: >> In another (Gerrit Code Review), we disable reflogs for >> the insane refs/changes/ namespace, as nearly every reference is >> created once, and never modified. > > Apologies for the tangent, but this is not true in the most recent > Gerrit implementation. We update refs/changes/CD/ABCD/1 and > refs/changes/CD/ABCD/meta in a single BatchRefUpdate, and we set a > reflog message on the BatchRefUpdate instance, which updates the > reflog for all refs in the batch. The reflog message on /meta is > important, and arguably it's useful to be able to correlate that with > the reflog on /1. > > If you think storing reflogs on patch set refs is going to be a > problem wrt on-disk storage, we should discuss this offline :) Reflog storage is a problem for Gerrit. It was a problem in early 2009 when servers had a lot less changes. Its going to be even more of a problem now. Sounds like we have to support reflogs in reftable, or something like it.